On 29 Dec 2012, at 16:28, Matthias Melcher wrote:
> So it seems they went from amalgamation to modularization in which the source > files are included into the main build. Modularization I can see the point of: I've used that myself, where we switched from compiling a lib to selecting *just the needed sources* directly into the build. However, AFAIK, an amalgamation of fltk would have two big disadvantages for me: - Since all of fltk appears to the compiler to be in one big source file, there is no easy way for the unused widgets to be left out of the build. With separate compilation units pulled into a lib, it is easy for the linker to skip over unused modules, but with a single source file, we then are dependent on the compiler identifying and eliding the "dead code" correctly. My experience suggests this will not work reliably, so we will end up with (possibly much) larger binaries due to "unused" code being included in the final. Of course, modularization addresses this problem in kind of the same way as the linker does... - Since all of fltk appears to the compiler to be in one big source file, the compiler will (in most, all?, cases) compile it using a single CPU. Which is nonsense on any modern machine. With multiple independent source files we can do "make -j8" or whatever and light up all the CPU's. This has a *big* impact on compile times - allows this Mac to compile fltk from cold in... Oh! it's finished... Further, the pro-amalgamation folks make some pretty tenuous claims, e.g. that the compiler can optimize better: frankly, a lot of that sounds like premature optimization... shaving a few cycles off a conditional test once (because the variable tested in now in a local scope) before pushing a few million pixels to the display is *not* going to produce a measurable performance gain! (Though shaving few cycles off each pixel would, of course!) If the build tools are going to make these sort of optimizations, I'd rather it was done as the LLVM folk are trying to do it, by retaining more of the compiler state into the linker phase and resolving things at that stage. This should be a much more flexible solution and ultimately is a win for all code... YMMV. For my part, I still think our static lib approach is the best fit for almost all use cases, and am not all that keen to change to somethng less time proven... _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
