On Fri, 5 Oct 2007 10:19:59 -0700 Michael Jennings <[EMAIL PROTECTED]> babbled:
> On Saturday, 06 October 2007, at 01:50:06 (+0900),
> Carsten Haitzler wrote:
>
> > i know how it works :) i just don't want to work with libtool's
> > abortion of a versioning system. i want to do it the old fashioned
> > way. .so major version changes == abi break. old calls removed or
> > changed abi or functionality. minor version == calls added, but no
> > functionality changes in existing calls. micro == no calls added or
> > removed, no functionality changes, just internal fixes/improvements.
>
> That's really how it works already, or at least pretty close. The
> middle number is micro, so if anything at all changes, you bump the
> middle number. If you add new API calls, you increment BOTH the first
> and third number; this will keep the major soversion the same and bump
> the minor version. If you remove any API calls, set the last number
> to 0 after incrementing the first number -- this will bump the major
> soversion.
>
> Is that what you were saying? If so, I totally missed it. Too early
> I guess. :)
yeah - that's what i;m saying. the fact that it has a different numbering
scheme just is painful - have to maintain 2 sets of numbers (yes - the forumla
is what you say to convert from package version to .so version going via
version-info). i'm only saying that we have a lump of shell script there
instead of a big wad of comments to do that for us. i.e. (in extreme ugliness
and a quick 1 minute job in an email:
VER=1.2.3.045
...
AM_INIT_AUTOMAKE(edje, $VER)
...
VMAJ=`echo $VER | awk -F . '{printf("%s", $1);}'`
VMIN=`echo $VER | awk -F . '{printf("%s", $2);}'`
VMIC=`echo $VER | awk -F . '{printf("%s", $3);}'`
SNAP=`echo $VER | awk -F . '{printf("%s", $4);}'`
version_info=`expr $VMAJ + $VMIN`":$VMIC:$VMIN"
AC_SUBST(version_info)
etc.
i.e. - just a lump of shell logic that takes the package version and creates
a .so version from it that matches by appeasing the libtool version info gods
and sacrificing a little math to them.
a slight problem here is that the .so version for evas is already 1.0.0 so we
are going to make an exception until release (need to check other libs too).
> > i want to keep the version of the package the same as the lib .so
> > version. it's cleaner and nicer. unless we go screw things up and
> > decide to name release versions without thought to compatibility -
> > then we need to do the below, but if we do things right, we don't
> > need to. if i break abi i will cal the package evas-2.0.0.tar.gz (or
> > whatever) as opposed to 1.0.0. i will make the package release # the
> > same as the lib .so version as needed.
>
> That will work as long as everyone understands that the *package*
> version is now a slave to the *library* version, not the other way
> around. We have to make sure the package is versioned based on the
> ABI, not just force the soversion to match whatever arbitrary package
> version we pick.
>
> It's nice and clean, that's true -- but it's going to take discipline!
indeed! absolutely. and i hope to maintain that discipline. until 1.0 i'm
reserving the right to break anything and ignore the version - but from 1.0 on
it's "slave to the abi" - we break abi - we go evas 2.0 or edje 3.0 etc. etc.
and onwards as needed, and not because of some marketing desires to call it 2.0
or 3.0 etc. :)
> > nooo - i don't want to make a new .so for each version with
> > -release. there is no need to put the link version directly in the
> > library name. i ONLY need to do this if i plan on having 2 or more
> > versions of the lib around AND application needing to explicitly
> > link at compile time to either a newer or older version. eg. gtk2 vs
> > gtk1. (at that point - mayaswell have new lib names too as the
> > version is now part of the lib name anyway as far as ld.so etc. are
> > concerned).
>
> Right, but it does give one the ability to use the package version
> when building the library without breaking soversioning. But if
> you're wanting to keep them in sync by focusing on the library
> version, not the package version, that's fine. It's just not the way
> most projects seem to think these days. :)
yeah - i know :) i'm trying to avoid that though by wanting to use .so
versioning as much as we can without juping into package versioning. that is a
work around after a project has been around long enough to require
compatibility back to older apps (gtk1 vs gtk2 for example) and allowing
development on older branches of the code etc. to continue. i hope not to get
into that boat :)
> Michael
>
> --
> Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]>
> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
> "The world isn't run by weapons any more, or energy, or money. It's
> run by little 1's and 0's, little bits of data. It's all just
> electrons! There's a war out there, old friend -- a world war, and
> it's not about who's got the most bullets. It's about who controls
> the information: what we see and hear, how we work, what we think.
> It's all about the information." -- Cosmo (Ben Kingsley), "Sneakers"
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> enlightenment-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
