I saw that an earlier thread revealed user interest in autotools and pkg-config support for cryptopp. ( http://groups.google.com/group/cryptopp-users/browse_thread/thread/4dbe083028ccf734/8f8d50bb795521b1?#8f8d50bb795521b1 ).
Both I and another person commented on your unused, yet linked to, Trac SF webapp in favor of such a thing: https://sourceforge.net/apps/trac/cryptopp/ticket/1 (oh, and, as a side note: two other bugs have been filed there as well ;-). See https://sourceforge.net/tracker/?func=detail&aid=2929579&group_id=6152&atid=356152 ) I would like to encourage cryptopp's maintainers to accept an autotools-based buildsystem and to support its use as well as the installation and use of a pkg-config macro file. Having pkg-config support would greatly ease integration of cryptopp into new programs' buildsystems. Using autotools for building provides users with the well known ``./configure && make install'' interface and gives them greater control over things such as easier prefix support. Also, a ./configure.ac script can be extended to do a better job of making some of the checks contained in cryptopp's current config.h and GNUmakefile (One such example would be checking if assembly fragment which would cause ICC to abort with an error actually does trigger the error, allowing assembly use to be disabled automatically but being prepared for a future release of ICC which may be able to correctly handle the assembly. Unfortunately, I don't have the skill, knowledge, or resources to try something like this ;-) ). Some distributions are already using their own autotools implementations and pkg-config macro installation, such as debian mentioned in the thread referenced above. Unfortunately, it looks like those who have written autotools/pkg-config scripts have not worked with cryptopp's maintainers and cryptopp's official distribution has remained without autotools/pkg-config support. This results in cryptopp installations looking different on different Linux distributions. A developer who works on a debian, for example, may see the presence of /usr/lib*/pkgconfig/crypto++.pc on his system and wire a check for the ``crypto++'' pkg-config macros; he would then find that anyone trying to compile his package on, say, a Gentoo or FreeBSD machine does not have the crypto++ pkg-config file. In fact, the Gentoo user will have both /usr/lib*/libcrypto++.so and /usr/lib*/libcryptopp.so while the FreeBSD user may only have /usr/lib*/libcryptopp.so (or .a, I forget) installed. The Gentoo user will find that /usr/include/cryptopp is a symlink to /usr/include/crypto++ and assume that this is the standard location for cryptopp headers to be installed when the official distribution actually installs into /usr/include/cryptopp. - http://ftp.de.debian.org/debian/pool/main/libc/libcrypto++/?P=*diff* (properly mangles AC_C_BIGENDIAN into IS_LITTLE_ENDIAN and IS_BIG_ENDIAN, but also seems to call some macros needlessly from configure.ac. Calls the library libcrypto++ (this is a deviation from GNUmakefile) but installs symlink from libcryptopp to libcrypto++.) - http://cvs.fedoraproject.org/viewvc/rpms/cryptopp/devel/ (oversimplistic, but good ideas concerning -version-info and a non-installed local.h. Doesn't install pkg-config header. Calls the library libcryptopp rather than libcrypto++.) - http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-libs/crypto%2B%2B/ (Uses GNUmakefile, but patches it so that it may be compiled into a shared library using libtool. Names library libcrypto++.so, but still provides the libcryptopp.so symlink.) I believe that if cryptopp's maintainer accepts and encourages use of a particular autotools/pkg-config buildsystem for cryptopp, some amount of confusion and per-distribution variation can be avoided. If packagers find problems with such a buildsystem, they will be able to provide patches for integration into cryptopp instead of replacing GNUmakefile with their own autotools version. http://cryptopp.com/#platforms makes it obvious that cryptopp cares about portability. I did write my own autotools patch, but I know I skipped over a number of portability hooks in GNUmakefile. My reasoning is that it is better to make it obvious that my patch does not have provision for some of the situations addressed by GNUmakefile so that those who encounter the problems may 1. still use a copy of GNUmakefile if necessary and 2. patch fixes into the autotools-based buildsystem and actually test that they fix the problem (which I wouldn't be able to do). Notes: - The patch reflects the changes that must be made to the VCS. To get the buildsystem up and going, run ``autorecon -vfi''. Don't forget to install a recent version of autoconf-archive (or download the ax_pthread.m4 macro and place it into /usr/share/aclocal/) - local.h.in is autogenerated by autoheader and local.h is generated after ./configure is run. This header will define the macros PROJECT to "cryptopp" and VERSION to the version specified in ./configure.ac to AC_INIT. It is the hope that these and other macros may be useful for *.cpp files. However, local.h should not be #includ-ed by the public API header files to avoid conflicts with other projects' config.h files (which will also define PROJECT and VERSION, for example). - I renamed adhoc.cpp.proto to adhoc.cpp because that allows for a cleaner Makefile.am and I couldn't guess any reasoning for having the buidsystem copy adhoc.cpp.proto to adhoc.cpp except possibly to avoid accidentally adding certain code to SVN. - I renamed GNUmakefile to GNUmakefile.old -- thus it is still accessible and a working method of building cryptopp. I also created config2.h.in, which is used to created config2.h which contains, most importantly, the IS_*_ENDIAN #defines. For systems which don't use autotools, there is config2.h.msvc which the user may rename to config2.h to regain the old behaviour (intended for MSVC users, obviously ;-) ). http://ohnopub.net/~ohnobinki/tmp/cryptopp-r479-crazy-autotools.patch Please feel free to contact and criticize my methodology or ideas. Thanks for any consideration, et cetera :-). -- ohnobinki Look out for missing apostrophes!
pgpnvcp6CGlTc.pgp
Description: PGP signature
