The workaround is to change this to /SUBSYSTEM:CONSOLE ...

Greg, can you please test the attached patch fluid_console.diff.txt against FLTK 1.4. Removing the "WIN32" flag builds fluid with /SUBSYSTEM:CONSOLE. The same patch does not apply cleanly to 1.3 but it's easy to adapt if you need (the change is in line 66 vs. 69, but context is different).

I tested this patch successfully in a "git bash" console and a standard DOS window. fluid does no longer background itself and you can see the error message.

The test I'm asking you to do is meant as a proof of concept, not a final solution. I can only simulate what you are doing, I don't use Makefiles to build on Windows (except with MinGW/MSYS which doesn't seem to be concerned).

I'm wondering how fluid generates FLTK's own .cxx/h files reliably during library builds without racing the compiler for the generation of the .cxx/.h files. Also, I imagine getting proper exit codes from fluid is affected by this.

Interesting question! I see what you mean (backgrounding, no exit code) but I don't know a good answer. I've never seen issues though. I could imagine that you'd need to run the build twice if it failed because the fluid file gets written "too late" for the build process (race) but I've never seen such issues in my builds.

It seems clear that it's not feasible to build fluid always as a console app because it would create the console window when run from the file explorer. In the "worst case" we could build two different executables (fluid and fluidc?). Making the decision a build option would be possible but likely not what we want (users would need two complete builds to get fluid for commandline and for interactive use).

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.