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.
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.)
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.
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?
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...
I am confused. So under mingw, "fluid-cmd.exe" is a Windows subsystem app, but it still provides stdout and stderr output? I thought that the whole subsystem trouble is at run time and caused by the OS rather than the build system or shell?
Also, if we stop providing fluid-cmd on mingw machines, existing build setups may still rely on its existence, right?
I'd assume Greg uses it in his Windows builds, for example?
Ya, I need to be able to generate executables via makefiles
that detect
failures from fluid via exit codes; Windows apps invoked from
a Makefile
immediately run 'in the background' and don't ever return exit
codes
indicating failures from code generation (-c flag).
Also, on headless machines there's no way to see the record of
failure
in the error logs of non-console apps. For instance a
permission problem
reading the .fl file, or a write problem for the .cxx/.h files
due to
code directory permissions or network file access issues.
I believe this is a straight-forward solution and it works well (tested
on macOS, Linux, Linux to MinGW cross-build, mingw-32, and VS 2019).
Ian, can you please test and confirm that this is OK for you?
(MSYS2/MinGW-w64 not tested by me).
On Sunday, 7 May 2023 at 21:20:08 UTC+1 Albrecht Schlosser wrote:
I believe this is a straight-forward solution and it works well (tested
on macOS, Linux, Linux to MinGW cross-build, mingw-32, and VS 2019).
Ian, can you please test and confirm that this is OK for you?
(MSYS2/MinGW-w64 not tested by me).
Seems good.
Tested on MSYS2/mingw64, and also MSYS/mingw32. Both fine.Cleaned everything out first, just to make sure, everything went smoothly.
..., at a complete tangent, I notice that the fractals demo runs *really slowly* under WSL on this machine, which seems odd because the OpenGL support (at least under Wayland, anyway) seems otherwise very good, reporting OpenGL version 4.2