Aleksey you now better what is necessary to be defined for plugin.
About packages ... every os has different name/structure convention. On some os-es package include all (executables, libraries, include files, docs). On other packages are split on binaries and include files. "make install" should install all in $(DESTDIR). How to create/What to include in a package responsible is package maintainer not developer.
May be we should have some wrappers as example for certificate:
===========================================
typedef struct xmlSecCert_s {
int crypto_id; ....
union {
....
#ifdef HAVE_NSS
CERTCertificate* nss;
#endif
#ifdef HAVE_OPENSSL
X509* ssl;
#endif
....
} cert;
....
} xmlSecCert
===========================================
and plugin structure
===========================================
typedef structure xmlSecX509_s {
....
xmlSecCert* (*get_key_cert) (xmlSecKeyDataPtr data);
int (*adopt_key_cert) (xmlSecKeyDataPtr data, xmlSecCert* cert);
....
} xmlSecX509;
===========================================
Aleksey Sanin wrote:
Hi, All!
I would like to make some changes to the current xmlsec build system. Currently we have followng situation:
*nix, Mac, etc. (autogen/automake/autoconf): We build all possible xmlsec-<crypto> libraries but only one xmlsec command line tool linked against "default" crypto library RPMs are build as follows: - xmlsec, xmlsec-devel: core xmlsec and default xmlsec-<crypto> libraries, command line tool linked against the default crypto libs. For my RPMs, default crypto means "openssl". - xmlsec-nss, xmlsec-nss-devel: libs for xmlsec-nss, no executable Windows: We build libraries and executable for the default crypto only.
I would like to change these and *aways* build all the xmlsec-<crypto> libraries and xmlsec command line tools linked with each of xmlsec-<crypto> libraries:
*nix, Mac, etc. (autogen/automake/autoconf): As before build all libraries (of course, user can disable some libraries from ./configure script). Build xmlsec1-openssl, xmlsec1-nss, xmlsec1-gnutls, etc. command line tools and later make a symbolic link "xmlsec1"-->"xmlsec1-<default crypto>". Probably there would be an option "--default-crypto" for ./configure script too. Also, RPMs would now have following structure: - xmlsec, xmlsec-devel: core xmlsec libraries, no executables - xmlsec-openssl, xmlsec-openssl-devel: openssl libs and executable - xmlsec-nss, xmlsec-nss-devel: nss libs and executable
Windows:
Build libraries and command line tools for all crypto libraries listed
in comma separated list in option "crypto" for the configure.js script.
After that, copy the "xmlsec-<default-crypto>.exe" to "xmlsec.exe"
where <default-crypto> is the first item in the "crypto" list (do we need
a separate "default-crypto" option?).
I would appreciate if John, Igor and everyone else interested can review this plan and send your comments/suggestions. I am going to make these changes next week on MS Crypto branch so we would have some bake time.
Thanks, Aleksey
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
