Re: creating C++ libs contitionally
Hi Mattias, * Mattias Barthel wrote on Wed, Feb 16, 2005 at 06:50:10PM CET: I am passing my Makefile.am's from 1.4 to 1.6. You should try to use a *recent* Automake. Like 1.9.x. Doing this I have encountered numerous incompatibility problems. Oh well. First when starting with 1.4, a part of the problem I bumped in to was that libtool did not really understand .dll as an extension of a lib, me having to make the Makefiles compatible with Windows. Libtool libraries are supposed to end in `.la'. The created .la files will be text files containing the real name of the library file(s). Which then may end in .dll, for example. BTW, which Libtool version do you use (try to use a recent one as well). The libs for Windows could also not be dependent of cygwin even tough the compiling environment was cygwin. I don't understand this sentence. Also, beeing C++ code libraries I could not use the AC_LIBTOOL_WIN32_DLL macro in configure.in because it seems to be dependent of that the lib is writtien in C. I don't understand this sentence. Finally I succeded to create a Makefile.am that worked in both environments except for a small warning from automake. automake: perl/Makefile.am: `vhcore.dll' is not a standard libtool library name But that was'nt really critical. Well, correct the things mentioned and then we'll see about any remaining errors. Regards, Ralf
targets to handle gnu dist procedures?
John Darrington (cc'd here), who maintains the GNUbik package, made this suggestion: With the new ftp upload procedures, shouldn't the automake targets be changed appropriately? In particular: The dist target should generate the package.tar.gz.asc file and the dist-check target should verify that this signature is indeed valid. I myself don't think it should be part of dist and distcheck. Doing the signature requires typing the pass phrase. It often takes a dozen runs of dist[check] before the release is actually ready (at least for me). I would be quite annoyed at having to do the signature stuff on every test run. Having a separate target to do it, however, could be useful. Maybe even make the directive file and sign it, too, with a variable that defaults to $PACKAGE for the directory name. (Some variables would also be necessary for the gpg invocations, of course.) What do you think? Best, karl
Re: targets to handle gnu dist procedures?
On Tue, 1 Mar 2005, Karl Berry wrote: The dist target should generate the package.tar.gz.asc file and the dist-check target should verify that this signature is indeed valid. I myself don't think it should be part of dist and distcheck. Doing the I agree. The 'make dist' and 'make distcheck' procedure *must* operate completely unattended. It must not require any CVS/network accesses, or user input. Many packages depend on this. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
