Moving this thread to fltk.development ... Please post follow-ups to fltk.development.
On 05.01.2012 18:15, Greg Ercolano wrote: >> Looks like fltree.patch would break the ABI, so we can probably not >> apply this in fltk 1.3.x. > > Good point. > > Hmm, we really need a way to get ABI breaking stuff into FLTK, > because if we don't, we forget to add it later. Good point, too. However, we could (and should) move STR's with ABI-breaking features to fltk-next-version-feature, and then we *should* look at this thoroughly when we go to the next ABI version. > Also, I think a lot of people compile static, and aren't concerned > with the ABI. Yep, so do I. And personally I always link static. > For interim releases, I have a suggestion. > > Perhaps we can create a configure(1) controlled macro flag called > "FLTK_ABI_FEATURE" that is default off, and could be used to > #ifdef out ABI breaking features. > > This would prevent a code fork, and leave a clear flag for devs > when the version bumps for ABI features that need to be enabled. I would even think of making this a "versioned" macro, so that we could selectively enable features based on the released FLTK version, e.g. #define FLTK_ABI_VERSION 010300 for FLTK 1.3.0. This way, new features could be enabled by defining the macro to have the value 010302 to enable features introduced in FLTK 1.3.2. Although this looks a little strange, since the default (released) FLTK ABI versions would always end in '..00', this could be interesting for someone who builds his own shared lib based on FLTK 1.3.2 and releases later apps and/or shared FLTK libs with the same ABI version. The sources would then need something like this #if FLTK_ABI_VERSION >= 010302 ... #endif This way, code ported to FLTK 3.0 would automatically enable all FLTK 1.3.x features left in the code with these macros. > To avoid #ifdef littering in cases where an ABI feature makes > many changes to a single file, perhaps too, we could standardize > on a file naming convention for ABI-breaking code. > > For instance, if I decide my ABI feature makes too many changes to > a particular .cxx or .H file to use #ifdef's for, I can simply > create a copy of the file, and put it in a special ABI_FEATURES > directory, and use a single #ifdef in the main file to #include it > if the configure(1) feature is enabled. eg: > > src/Fl_Tree.cxx -- default build file > src/ABI_FEATURES/Fl_Tree.cxx -- ABI feature version of this file > > .or some such. > > So then inside the normal src/Fl_Tree.cxx there would be: > > #ifdef FLTK_ABI_FEATURE > #include ABI_FEATURES/Fl_Tree.cxx > #else > [contents of normal file here] > #endif /*ABI_FEATURE*/ > > So I imagine with this arrangement, when FLTK bumps its ABI version, > it's clear to the devs what to clean up; the #ifdef's are removed, > the feature file is merged into the normal file, and the feature file > would be removed. > > Or something like that. Hmm, for really large changes and additions, this might be a way to go, but for small code changes, duplicating entire files would probable be a maintaining nightmare. Fixes to ABI-independent code parts would have to be duplicated etc.. Although I can see your point here very well. > This may have some interesting implications for doxygen, > perhaps some discussion is needed on that. Yep, one more point to leave all changes in one file, maybe. Doxygen has one directive "\since" that could be interesting here. > This all might help solve two common issues we've had in the past: > > o Not being able to add ABI breaking features we want > o Forgetting to add ABI breaking stuff when we bump the ABI version Agreed. However, not to forget: testing and bug reporting and fixing could become "interesting", since we must also know the ABI version the reporter used for his special case. And dev's might need to check their changes against different ABI versions... Anyway, having such a feature and using it with care would IMHO be an advantage. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
