[xmlsec] build system changes

[Roumen Petrov]

  What about crypto lib to be loaded dynamically, i.e. xmlsec core to 
have "plugin architecture"?

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
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>
>