| |
| |
On 10/1/22 05:32, Albrecht Schlosser wrote:
On
10/1/22 14:00 Ian MacArthur wrote:
All,
So, what *does* fluid-cmd.exe do?
It gets built by the cmake builds on Windows (the Makefile build
doesn’t seem to build it?) but I cannot tell what it does - I
can’t read cmake files very well, but it seems to be built out
of the same things as “regular” fluid... and..?
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.
This is super bad in a production environment,
where build errors MUST stop the build,
otherwise build errors would go undetected.
In my case I was building a 3rd party app in a context where the
.cxx/.h files had
weird network permissions (ACLs vs unix chmod), preventing them
from being overwritten
by fluid, causing stale .cxx/.h files to remain behind after
fluid finished, and since the Makefile
never saw an exit code, caused the old code in the new binary,
causing old behavior in new
releases. This was BAD BAD BAD.
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"?)
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, esp. in a
parallel processing context where several
might run at once, such as from a parallel make.
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.
What is it, what’s it for, how/why is it
different from “regular” fluid, etc.?
And why does it hang?
See above. It should not make a difference and it did not for me.
Other Windows/MSYS2 magic seems to cause these hangs but 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.
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.
--
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/d1056feb-c954-51da-1c29-2716e4f362ae%40seriss.com.
[ Direct Link to Message ] | |
|
| |
