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.)

And...

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.

Where that byte is moves about with the PE header structure though, at least in principle, though in my experience (with gcc toolchains anyway) this is pretty much always byte 0xDC. (I do not think we can just assume it is byte 0xDC though!)

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.

That said, the mingw toolchain does not have editbin, AFAIK - though the Msys shell doesn't need the fluid-cmd anyway since it does not drop the stdio stream for Windows apps.

Actually... that might be an option... Can we have the cmake script detect the presence of the editbin tool? 

I assume the MS toolchain, which "needs" the fluid-cmd built as a console app, does provide it, so:

Build fluid as a "Windows" subsystem app normally, fluid.exe

cp fluid.exe fluid-cmd.exe

If find editbin then editbin /subsystem:console fluid-cmd.exe

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...