[xmlsec] build system changes

[Aleksey Sanin]

> Please let us know your motivation for these changes.

The idea behind these changes is that I would like to provide
user an ability to install xmlsec-nss command line tool, for example
(*nix) and have libraries for all crypto engines packaged in Igor's
Windows binaries.

> As far as licensing, the important requirement is that application 
> binaries and
> shared libraries only need depend on the crypto engine library that is 
> suitable...

This is very similar to what I want to do: core and packages for each 
crypto engine.
The reason to breake different development files in different packages 
is that
someone might have openssl installed but not nss. There is no reason to 
force
a guy to install nss to just only be able to install dev files for 
xmlsec-openssl.


> As for the xmlsec1 tool, I think it's unfortunate that we need to 
> expose the
> crypto engine differences to the poor command-line user...

Well, it's not quite correct. There is almost no difference in command 
line tool
API and a very little difference for xmlsec internal API (for example, 
xmlsec
command line tool is written in a way that there is no compilation 
differences
at all). The only reason why I would like to compile xmlsec-<crypto> command
line utilities for all crypto engines is a situation of an NSS guy who 
wants to use
xmlsec command line tool with NSS (why s/he have to install OpenSSL for 
that???)



And finally, all this is driven by Windows. Currently we do build only one
OpenSSL linked libraries. As soon as we have MS Crypto it seems natural to
compile both in the same time. Thus the idea to change it. On *nix side 
I just
want to have a similar thing. Almost nobody would see the difference. 
It's just
a matter of adding few additional files to the packages.


Aleksey