On Mon, Mar 30, 2015 at 4:55 AM, René J.V. <[email protected]> wrote: > On Monday March 30 2015 01:40:39 Jeremy Huddleston Sequoia wrote: >>Actually, I think I'll just do similarly and revbump all dependents. >>Unfortunately, that means anyone using the library for their own projects >>will need to recompile, but that's probably better than the maintenance >>headache of being different than upstream going forward. Hopefully they can >>manage to version themselves correctly now that they're on cmake. > > I'm guessing this is about the compatibility and min/max versioning stored > in the dylib, so providing a transition period would mean copying dylib(s) > rather than symlinking to them? Still, if you copy only .N.dylib variants > that are stored in dependent binaries (and change their internal versioning > info) that should satisfy existing binaries until they're recompiled, no? > > @MLD: we could probably pull the same trick with the port where we bump down > the compatibility version, no? (qca? Can't remember which one it is ATM..) > > R.
The 'problem' is that cmake automates the setting of the current and compatibility versions from the VERSION set in CMakeLists.txt. There is no fine control in cmake for setting a compatibility version that is different from VERSION (which potentially might be worth requesting as an enhancement to cmake upstream). > _______________________________________________ > macports-dev mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
