David, the macro is fairly simple, not really big (even I understand what this macro does :-) ). So, probably I could copy it into the local m4 directory, rename it for example to "local_libgcrypt.m4" and also rename the macro names if necessary to avoid confusion with the original macro. Thus we have a local implementation. Putting in the refrence to the original macro would enable us to track this.
Unfortunatly libgcrypt also uses a non-standard way for pkg-config, it has its own mechanisms (shell script) that the libgcryt package installs (usually in /usr/bin). This is called "libgcrypt-config". This is why the maintainer also introduced an own macro. IMHO having a local copy is the safest way - on the other hand yet another additional unnecessary "manual" dependency to maintain. I also was puzzeled when I discovered this circular dependency you mentioned. I'll contact Werner Koch to see if he has some ideas how to solve this problem. Regards, Werner David Sugar schrieb: > 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 >> Ccrtp-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/ccrtp-devel _______________________________________________ Ccrtp-devel mailing list Ccrtp-devel@gnu.org http://lists.gnu.org/mailman/listinfo/ccrtp-devel