| |
| |
On 10/2/22 08:05 Greg Ercolano wrote:
On 10/1/22 05:32, Albrecht Schlosser wrote:
On
10/1/22 14:00 Ian MacArthur wrote:
The only difference is that it's a Windows Console (-mconsole)
rather than a Windows GUI (-mwindows) executable. This was done
on request (by Greg) because some fluid issues (e.g. not being
able to access remote file systems or other errors) would not
display an error message if built as GUI exe as it was before.
Yes, though more importantly: the Makefile would not get a
proper exit code from fluid
when it failed, causing a build invoking e.g. 'fluid -c
foo.fl' to sail right through
even if the creation of .cxx/.h failed due to a write error.
Oh, thanks, I didn't know that fact.
Anyway, I noticed this because a 32-bit
mingw checkout choked at build for me - stuck in
fluid-cmd.exe, just sitting there... indefinitely...
Hmm, I'd be curious what fluid-cmd's were being invoked (was
it the -c flag? e.g. "fluid-cmd -c xyz.fl"?)
During the build only `fluid-cmd -c xxx.fl` commands are executed.
For sure that should just write out files, print errors to
stdout/err and /exit/, and not pop any GUI dialogs
so as to prevent any kind of interaction with the GUI, ...
fluid should be avoiding ANY gui calls during a -c operation;
all -c flag handling in main()
should precede any initialization or use of FLTK calls.
Hopefully there's no global window manager stuff being
triggered before main() in fluid,
otherwise there might be contention with the window manager in
a parallel build
scenario, where two or more fluids run at once, contending for
the window manager
and blocking each other. I hope that's not the case.
... And why does it hang?
... I have no idea how to debug this (other than printf
statements in fluid, maybe).
I'd probably suggest attaching a debugger to one of the hung
processes
to see what it's stuck executing.
I know that this is possible but I never tried this. Seems like
something I need to learn so I can try this the next time my build
hangs in fluid-cmd. Or maybe Ian, could you try it in your
situation?
If it's hung during a -c command in window manager stuff, then
we may have
to move the -c option to a separate binary that doesn't link
with fltk, just so
it can be a purely 'headless' command line tool.
This is something Matt did always take care of and I test this from
time to time. It's easy to test in a "normal" (non-wayland) build on
Linux by deassigning the DISPLAY environment variable, e.g. in bash:
$ unset DISPLAY
$ cd fluid
$ ./fluid -c about_panel.fl
$
You can test this yourself. If fluid (or fluid-cmd) returns w/o
error message it works, obviously w/o opening the display. If you
run `fluid` only you'll see the error message:
$ ./fluid
Can't open display:
$
Note: for a wayland (hybrid) build you'd have to assign
FLTK_BACKEND=x11 to enforce the x11 backend.
Although we're talking in this thread about Windows it shouldn't be
different on that platform. I don't know how to *verify* this on
Windows though other than adding printf's (or setting a breakpoint
in a debugger) at appropriate places in the code.
--
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/36c18ace-2025-bde9-09d1-11d7180a03aa%40online.de.
[ Direct Link to Message ] | |
|
| |
