[xmlsec] versioning and library naming policies

Aleksey Sanin aleksey at aleksey.com
Tue Apr 1 11:41:29 PST 2003


I think I come up with a plan that should satisfy everyone (but I don't like
it much myself, see comments bellow). Let me know if it will not work for
you or you have any other ideas. All the changes bellow apply to Unixes 
only.
If you don't care about Unix then nothing changes for you.

0) Package name.
 From now on the package name changes from "xmlsec" to "xmlsec-0.0",
"xmlsec-0.1" and so on.

1) Include files.
The include files are move from "$(prefix)/include" to 
"$(prefix)/include/xmlsec-0.0",
"$(prefix)/include/xmlsec-0.1", ... folders. The "xmlsec-config" script 
is updated and
will return correct new include folders. If you hard coded the xmlsec 
include
folder in your Makefile the you'll have to change it manually.

2) Library files.
2.1) Library files are moved from "$(prefix)/lib" to 
"$(prefix)/lib/xmlsec-0.0",
"$(prefix)/lib/xmlsec-0.1", ... folders. The "xmlsec-config" script is 
updated to return
correct paths. Also all the libraries are build using "-R" and "-rpath" 
libtool
options. If you use libtool for building your application then you 
should get correct
linking options and "$(prefix)/lib/xmlsec-N.M" folder will be added to 
library
search path for your application.  If you don't use libtool then you'll 
have to add
"-Wl, -rpath -WL, $(prefix)/lib/xmlsec-N.M" to your makefiles.
2.2) Library names have changed from "libxmlsec.so*" to 
"libxmlsec-0.0.so*",
"libxmlsec-0.1.so*", .... The static library names have *not* changed.

3) xmlsec-config script
xmlsec-config script have updated to return new paths, etc. From now on 
there will be
two scripts: xmlsec-config and xmlsec0-config (xmlsec1-config, ...) If 
you want to link
against particular xmlsec version, use the "numbered" version.

4) man pages
Same as xmlsec-config script: two man pages "xmlsec.1" and "xmlsec0.1" 
("xmlsec1.1", ...).


Problems:

I don't like conflicts in items 3) and 4) by I don't have a good 
solution. I also don't like
that because of 2.1) you'll need to either use "-rpath" option for 
building your app
but I don't see any other good solution that provides a way to have 
multiple versions
for static libraries. Everything works just fine if we say that multiple 
xmlsec packages
(xmlsec runtime) is allowed on the box but only *one* xmlsec-devel 
(xmlsec sdk).
And I wonder if anybody thinks that we go with this. This perfectly 
solves all the problems
with items 2.1), 3) and 4).

Comments, suggestions, ideas?

With best regards,
Aleksey















More information about the xmlsec mailing list