Since the distributed tarball contains a pre-built configure, those receiving tarballs will be fine so long as our default build machines have a gcrypt recent enough on them or the missing .m4 files placed there. This will as you noted cause problems for those who use a cvs/svn checkout directly and/or rebuild configure and do not have current gcrypt, however.
I am assuming you are referring to "libgcrypt-devel" in terms of a package on RPM based GNU/Linux distributions such as those provided by RedHat, Mandriva, etc. Generally when we build RPM spec files we assume and require all devel packages to be present anyway, and in any case the devel package would be needed to link and use gcrypt, so I do not see this as a limiting issue by itself. My concern is how this might effect those building from checkout on machines with older releases of gcrypt installed from before the macro was introduced. I am also concerned that it is being called a "AM_xxx" macro but yet is not distributed as part of automake itself, as it does confuse where and when you can expect to receive this macro. An underlying assumption is that it will be used to test for a library that may not be present, but yet forces one to provide the library to rebuild configure to test for it's potential absence. This to me seems like a kind of funny circular dependency, especially given that our packages only optionally use gcrypt rather than require it, and hence this does require someone to install stuff to rebuild configure to check for something they may not want to actually build the library with. However, they could always run configure with options to disable checking for gcrypt if that is desired, so you may be correct that the impact could be rather minimal. Where I might find it initially troublesome is on some of my test boxes, for example for opensolaris, or some of the BSD's, or on my auto-build system when rebuilding from cvs on an older distro, which may have older distributions of gcrypt packaged and installed by default or may not normally have gnupg/gcrypt installed at all. I generally want to keep the library versions and configurations of those boxes pure when building packages to match the distro, and those are usually built directly from svn checkout. I could however add a local aclocal for my build machines with this macro and modify some of my upper level stuff to make sure it is parsed when rebuilding configure. We actually do a similar check in GNU SIPWitch for gcrypt (we use gcrypt to optionally support SIP digest routines), so whatever we choose to do for ccrtp will effect that package as well. If the macro is small enough and does something simple enough then maybe another option would be to use a local version or embed the functionality directly in our configure.ac script. I will have to think about this and see what others might say. Werner Dittmann wrote: > David, all, > > just recently the maintainer of libgcrypt (Werner Koch) released > a new version. Because of this the "simple" detection of libgcrypt > in the "configure.ac" script is not longer feasable. To > correctly detect and configure the libraries and paths for libgcrypt > the macro AM_PATH_LIBGCRYPT should be used. The libgcrypt-devel > packet contains this macro and installs it in the correct m4 system > directories. > > The use of this macro implies that a system that runs the "reconfig" > script to recreate the "configure" script needs the libgcrypt-devel > packet. Would this be a severe constraint? IMHO it's not severe because > libgcrypt is the basic crypto library for Gnu Privacy Guard (gpg) that > is available for most systems (Linux, BSD, Windows, OS-X?). > > Once "configure" was created it will detect if libgcrypt is available > or not, and falls back to openssl if necessary. > > If this modification is ok I would re-test the whole stuff on my system > and then do a check-in. > > Regards, > Werner > > > _______________________________________________ > Ccrtp-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/ccrtp-devel
begin:vcard fn:David Sugar n:Sugar;David org:GNU Telephony email;internet:[EMAIL PROTECTED] tel;work:+1 201 215 2609 url:http://www.gnutelephony.org version:2.1 end:vcard
_______________________________________________ Ccrtp-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/ccrtp-devel
