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
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
