> 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.

Also, I think a lot of people compile static, and aren't concerned
with the ABI.

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.

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.

This may have some interesting implications for doxygen,
perhaps some discussion is needed on that.

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


_______________________________________________
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs

Reply via email to