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