Re: [fltk/fltk] windows+fltk1.3.x+1.4.x: "fluid -c somefile.fl" fails without error if .fl file unreadable (#224)

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.issues  ]
Previous Message ]New Message | Reply ]Next Message ]

Re: [fltk/fltk] windows+fltk1.3.x+1.4.x: "fluid -c somefile.fl" fails without error if .fl file unreadable (#224) Albrecht Schlosser Apr 27, 2021 top right image

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.

Direct Link to Message ]
bottom left image   bottom right image
Previous Message ]New Message | Reply ]Next Message ]

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.