On 01/06/12 06:28, Albrecht Schlosser wrote:
> 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.
Right, agreed.
I'd say perhaps some message in the STR that says
it's implemented as an ABI feature, but remains open.
(perhaps a new state for the STR that could be 'ABI feature',
so that it's not exactly closed, but not unresolved either.
Maybe we have such a state already that is close enough)
I could see a possibility where an ABI feature might be
added that has no corresponding STR. (The feature might have
been added as part of normal development)
To close that hole, perhaps we should add a requirement
to the CMP so that all new .0 releases must first resolve
all FL_ABI_FEATURE's are resolved before release.
So in other words, make sure any source files that show up
in 'grep -r FL_ABI_FEATURE .' get resolved.
>> 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.
I see, hmm, sounds like a neat option.
Not sure if it might somehow create strange incompatibilties
if a user pulls 1.3.2 but only enables 1.3.0 ABI features.
A 1.3.0 feature might have been modified in 1.3.1 to track
features added in 1.3.1, so unless the 1.3.0 macro is modified
to 1.3.1, it would break.
As a dev, I'd kinda expect if someone pulls 1.3.2 and enables
ABI features, they'd get /all/ features to date for that stream,
so that there are no interdependency issues between ABI features.
> 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.
Interesting.
As long as it doesn't create weird interdependency issues
it should be OK. Not sure.
>> 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.
Right; the dev would just use #ifdef's within single code
unless it gets too ugly to manage, and only then fall back
to making separate file copies if absolutely needed.
>> 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.
Good..
>> 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...
Right. Hopefully it's a very rare case where ABI changes
would affect other widgets, since even ABI changes should
still be /API/ compatible.
In a case where an ABI feature might affect other widgets,
that might be a good reason to do what we do now; defer
the changes to the next big release.
I think this thing I'm proposing would be specifically
for those /simple/ nagging little ABI tweaks that only
affect DLL users, and would hinder development if not added.
If it's OK, I'd like to try this with the current Fl_Tree
ABI issue, and see how it goes. This way we can find out
what issues might be caused.
For now to enable the ABI features we can tell people
to hack #define FLTK_ABI_FEATURE (or whatever) into the
config.h file, and later make it configure(1) controllable.
I don't know how to tweak configure(1), so hopefully
we have an expert here on how to add this.
I suppose when an ABI feature is added, it should be
reflected in e.g. the CHANGES file.
For CHANGES, I could see:
----
CHANGES IN FLTK 1.3.1
[..usually entries here..]
ABI FEATURES IN 1.3.1
These features are enabled with the FL_ABI_XXX flag.
> Fl_Tree optimizations for speed with large (100k) trees
> Fl_Xxx modified to support zzz
----
This way users can see what they're going to get
when they enable FL_ABI_FEATURES.
Or perhaps a separate file would be better, as then
configure(1) could have an option:
--list-ABI-features -- Lists the ABI features available in
this release
..which simply shows the contents of that file.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
