On 09.01.2012 00:56, Greg Ercolano wrote: > On 01/08/12 04:48, Albrecht Schlosser wrote: >> This is *not* dependent on linking statically or dynamically! If your >> version of the FLTK lib is compiled with another ABI version macro than >> you define in your application, then you *have* different ABI versions >> in your application. > > Oh, I see what you're getting at. > > But let me back up for a sec, as I think I'm missing something > about how this version number feature might be used (vs. it > just being a boolean that's either 'on' or 'off'. > > 1. Would you ever build FLTK with one ABI version number, > but then try to compile/link against it with another? > And if so, for what specific purpose?
No, I wouldn't, and nobody should do this. That would be ABI chaos. > 2. If you had FLTK 1.3.2 on your system, what reason would one > want to enable ABI features for that build that would be anything > other than 10302? (ie. setting it to 10300 would just get ABI > features added in 1.3.0, but why would you want that, and why > should we support it if one of those features was then modified > in 1.3.1 or 1.3.2?) It is more the other way around: When we (or any official (e.g. Linux) distro) deploy FLTK 1.3.2, then the ABI version *MUST* be 1.3.0, since we must never change the ABI during patch updates (1.3.1, 1.3.2, ...). This is the only way to ensure ABI compatibility, and Linux distros usually include shared libraries. Now you suggested to enable ABI-breaking features *during* patch updates (see above), and I agreed that this would be good. But then it must be enabled explicitly by a configure option or something else. However, you must still make sure that the header files for application development are in sync with the library that has been built before (by a Linux distributor, yourself, or any other person). This would usually be the *.*.0 ABI version (see above), but if a software developer needs a special feature that requires an ABI change, the he'd have to do two things: - compile the library with the ABI feature enabled - compile his program with the ABI feature and link statically (linking statically wouldn't be a MUST, but recommended). > I'd think the version# would simply be set at FLTK build time, > 'baked' into one of the .H files, and then could not be changed > unless the lib were rebuilt. Okay, but it would be difficult (at least I think so) to change the file FL/Enumerations.H (where this belongs in), unless you can do it with a compiler option/macro as I suggested. Otherwise you'd have to edit that file manually. > Any kind of weirdness that might happen if the user rebuilt > FLTK with a different ABI version#, but didn't recompile their > own code (possibly getting a mismatch) could get similar nutty > behavior if they switched FLTK versions but didn't rebuild, > and we don't really protect them from that (I don't think? Or do we?) No, that's the problem. My proposal is to improve this. > Sorry for the step backwards, but I guess I didn't get how the > version# thing would be applied, and I suppose I'd need to 'get it' > in order to understand in order to understand the OVERRIDE and > fltk-config options. In my mind once the lib is built, these values > would not want to be changed by fltk-config or compiler flags. The OVERRIDE option was *one* possible idea to switch to another ABI version w/o editing a FLTK source/header file. The drawback is that you would have to use the same option for your app's compilation. One way to achieve this was to use fltk-config (for commandline junkies ;-), but the Windows IDE's also have the ability to add a compiler macro by the user. I wanted to avoid the need to edit source files. The reason why I suggested a version number and not a simple on/off switch is that someone could enable all 1.3.2 ABI features, and then upgrade the sources to 1.3.3 or later, but still keep ABI compatibility with the previous headers and shared libs, even if 1.3.3 or later added other ABI breaking features. Albrecht _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
