On 01/07/12 02:29, Albrecht Schlosser wrote:
>> 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.
>
> Good idea, but who will control this? ;-)
LOL, well with regards to the CMP, I guess I can add it,
and with regards to the 'grep', I suppose whatever makefile
we have that preps FLTK for a new release could run it,
and fail if any FL_ABI_FEATURE values are found in a .0 release prep.
(I don't actually know the release procedure -- I guess Matt
has been making them lately)
> Agreed. We should definitely use this with care and only if we think
> that the change is needed locally, e.g. for one widget only, something
> like ...
>
>> 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.
>
> I don't know if it's OK (we need more opinions), but I'd vote for
> it if used with the version number, i.e. in this case something
> like FLTK_ABI[_VERSION] = 010301, since this would be the next
> official release.
Mainly, I just want to check it in before I forget everything ;)
> IMO config.h would be the wrong place, this is only used in the FLTK
> lib and not available to end users. However, the developer may need
> a way to tell if a particular feature is available (if the ABI feature
> is also an API extension or modification, which should be allowed as
> well). Hence, it would probably have to be in FL/Enumerations.H ?
Yes, where ever's best. I'm not fully knowledegable about
FLTK's release stuff.
> Well, here's an idea: we can tell the users to define the feature
> macro when compiling the FLTK lib *and* the application as the
> *same* value, and then FL/Enumerations.H could contain:
>
> #ifndef FLTK_ABI_VERSION
> # define FLTK_ABI_VERSION 010300
> #endif
>
> However, if someone would compile his app with another value than
> the FLTK library (.dll, or .so), then this would be a big problem,
> because then you *would* have ABI differences. Better ideas, anybody?
My idea was (in a previous post I think) that if this macro
is enabled, there'd be a compiler #warning if anyone tried
to build dynamically against FLTK built with this flag enabled.
That would prevent people from creating a binary that wouldn't
work on other systems.
Or, perhaps the macro would affect the file naming of the .dll's
we generate, so that it has a special suffix (eg.
fltk_images_1_3_0_AF.dll
or some such) that indicates is a special feature release of 1.3.0.
This would prevent accidental inclusion of the wrong dll/so's at
runtime..?
> IMHO this would be too much work, and since all these ABI features
> will be included in later versions anyway, we'd have to maintain this
> also when we switch to the next ABI release (minor or major version).
> And, BTW, configure is not used by IDE users and CMake etc.
Right, though whatever features we do supply in configure
probably have similar techniques in those.. I don't know what
those are.
It seems like VS options are minimal; DEBUG/RELEASE and CAIRO
are the only options I've ever seen (or needed).. if there's more,
I guess I don't know about them.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
