I was looking at the build output from recent builds and I note that
for WIN32 targets the builds are compiling everything twice, once for
fluid and then again for fluid-cmd.
The same is true for fltk-options and fltk-options-cmd now too, of
course.
fltk-options consists of only one source file, this shouldn't matter
(see below for fluid).
This seems a bit redundant, since the only actual difference is in
the final link stage of the build.
Yes, indeed, I can confirm this.
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.)
I can take a look into it. I'm not sure if we can avoid it in a
"naive" CMake build but I know I did such things already by building
an intermediate object library and linking against this object library
(this is trivial). This lib would obviously not be installed in the
final install step.
Fixed in commit 712fc72fef6e92851b69f9d6e448b3ea7cd10215.
This compiles only the main program source file for the executable and
links all other fluid objects from a new temporary object library (which
are compiled only once).
Compiling the main program (e.g. 'fluid.cxx') seems to be necessary
because we need at least one source file. This applies to all 'fluid*'
and 'fltk-options*' executables.
For fluid we can have up to three executables: fluid, fluid-cmd, and
fluid-shared. The latter is not really necessary but included for
testing if shared libs are built.
I believe this is a straight-forward solution and it works well (tested
on macOS, Linux, Linux to MinGW cross-build, mingw-32, and VS 2019).
Ian, can you please test and confirm that this is OK for you?
(MSYS2/MinGW-w64 not tested by me).
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
