On 31.12.2012 13:48, Matthias Melcher wrote: > But back to amalgamation/modularization: > > technically, there is no difference between > > g++ myApp.cpp fltk/Window.cxx fltk/Widget.cxx fltk/run.cxx -o myApp > > and > > g++ -c fltk/Window.cxx > g++ -c fltk/Widget.cxx > g++ -c fltk/run.cxx > ar WIndow.o Widget.o run.o -o fltk.lib > g++ myApp.cpp -l fltk -o myApp
Well, in my experience there *are* big differences between these two ways. See comments below. > And while the second version seems more involved, it is actually much faster > because it only needs to run those lines that are associated with files that > actually changed. Here you assume that you also have a make system that decides what to compile from (a) changes in source files and (b) dependencies. This is not the case in the simple compile-and-build case, especially if we compare with the all-in-one-file amalgamation. > Setting the linker correctly will remove all unused code from the final > executable, so there is no harm in adding more files. Again an assumption that doesn't hold generally. If we are talking about default linker behavior, then the second method would select only used files, whereas the former would include all object files (at least from my knowledge and experience). "Setting the linker correctly..." would IMHO be very much platform- dependent and can not be assumed to be even possible in all cases, at least NOT for the first case. > FLTK does require a pre-compile configuration pahse though, simply because it > supports so many configurations, especially for X11. The advantage is that > FLTK will run on even the smallest embedded Linux device, to a certain degree > even without X11. There is simply n way to do that at compile time only. I agree, but what does the pre-compile phase do? It writes a config file with some #define's (and/or omits others). Nothing of this would preclude an amalgamation. But then again it's not THAT simple to use just one file for all configurations. That's the point. > To me, it's fine if users want to compile fltk cxx files instead of using the > library. We could provide a default configuration that "just works" for > current machines, but for older systems, we still need autoconf. Yup, so we'd need n (how many?) pre-configured and platform dependent header files (config_windows.h, config_mingw.h, config_X11.h, ... ?) and maybe only one amalgamation file that includes all sources. Maybe... Again, I don't think that we should discuss changing the main FLTK development way. It's good as it is, but an amalgamation could make sense as an additional way for (a) beginners and (b) people who like that amalgamation idea for whatever reasons. -- Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
