| |
| |
On 4/24/23 12:54 imacarthur wrote:
I was looking at the build output from recent builds and I note
that for WIN32 targets the builds are compiling everything twice,
once for fluid and then again for fluid-cmd.
The same is true for fltk-options and fltk-options-cmd now
too, of course.
This seems a bit redundant, since the only actual difference
is in the final link stage of the build.
Yes, indeed, I can confirm this.
It seems like we could just compile everything once, then
have two linker passes - though I don't have the necessary
cmake-fu to know the ways of that. (The obj files currently
generated are identical between the two branches, as best I can
discern.)
I can take a look into it. I'm not sure if we can avoid it in a
"naive" CMake build but I know I did such things already by building
an intermediate object library and linking against this object
library (this is trivial). This lib would obviously not be installed
in the final install step.
TBH, if we don't mind a hack, we could just compile and link
everything once: the only actual difference between a "console"
app and a "Windows" app is a single byte in the PE header block,
so if we wanted (and I have done this in the past...) we can
just compile for "Windows" and then hexedit the subsystem byte
to create the "console" version.
I'm strictly against such hacks if they can be avoided, see my
suggestion above.
Strictly speaking, the subsystem ID is a 16-bit short, but
the values are either 0x002 for Windows or 0x003 for console, so
only the 0x02 or 0x03 values ever change.
...
If we have the MS editbin tool, we can also just build for
Windows and then do:
editbin /subsystem:console wibble.exe
To convert the subsystem in a more controlled fashion than
just a hex hack.
... Can we have the cmake script detect the presence of the
editbin tool?
Even with such a tool and the required detection in CMake this would
probably be more complicated than just linking twice from the object
library.
But thanks for investigating and for the hint that such a tool
exists. I didn't know that.
On mingw systems that do not have editbin, we just end up
with a "fluid-cmd.exe" that is actually a Windows subsystem app,
but that's OK because under mnigw / Msys that just works
anyway...
When I added 'fluid-cmd' I wondered if we needed this for all
Windows builds or only for MSVC but I decided to build
it for all Windows builds, just in case (later this was copied by
Matt for fltk-options). If we can reduce the build of the
'*-cmd.exe' to just linking it's even less important to consider if
we could avoid building these for MinGW etc..
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/661dbfa6-33a6-9efc-3f0e-a2324ff2601f%40online.de.
[ Direct Link to Message ] | |
|
| |
