FLTK logo

Re: [fltk.coredev] On the building of fluid-cmd and fluid...

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.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: On the building of fluid-cmd and fluid... Albrecht Schlosser 13:20 May 07  
 
On 4/24/23 15:17 Albrecht Schlosser wrote:
On 4/24/23 12:54 imacarthur wrote:
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).


--
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/490e95c0-315a-93c0-909c-0e69370fd1b5%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

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