Hi, Fabrizio Some distributions have a wrapper for the autotools (initially from Mandrake, I think) that is trying to divine what version of autotools to use, since usually there are a number of versions installed and you can specify the version to use in the configuration files. The output you show seems to derive from a mismatch (output shows that automake-1.8 generated it. If you do "aclocal --version" you may get a different one). You can try once with giving explicit versions on the command line. aclocal-1.9 automake-1.9 autoconf-2.59 ... The openssl header worries me more, because I actually included some tests, one is AC_CHECK_HEADER([openssl/ssl.h], [],[ssltests=failed] ) Can you give me more info on how it failed? What header file was missing? Then I will improve the tests. Thanks, Derek On Wednesday 12 October 2005 15.39, Fabrizio Furano wrote: > Hi, > I am testing and using the stuff at home in my Mandriva 10.2 system. > > The autoconf phase works quite OK, I get only some stupid warnings, but > I believe that they are not xrootd related. I am using automake 1.9. See > the output below. > > The only problem I found is that configure does not check for the > presence of the openssl header files in the system. Now I installed them > and the build is working fine so far. > > Fabrizio > > ------------ > fabrizio@oasi 15:07:46 ~/Park/xrootddev/xrootd>aclocal > /usr/share/aclocal/gtk.m4:7: warning: underquoted definition of > AM_PATH_GTK > run info '(automake1.8)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending-aclocal > /usr/share/aclocal/g-wrap.m4:7: warning: underquoted definition of > AC_GWRAP_CHECK_GUILE > /usr/share/aclocal/g-wrap.m4:23: warning: underquoted definition of > AM_PATH_GWRAP > /usr/share/aclocal/audiofile.m4:12: warning: underquoted definition of > AM_PATH_AUDIOFILE > > > > fabrizio@oasi 15:07:51 ~/Park/xrootddev/xrootd>aclocal --version > aclocal (GNU automake) 1.9.4 > Written by Tom Tromey <[log in to unmask]> > > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is > NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > PURPOSE. > fabrizio@oasi 15:08:01 ~/Park/xrootddev/xrootd> > --------------- > > Fabrizio > > On Wed, 2005-10-12 at 09:42 +0200, Derek Feichtinger wrote: > > Hi, Peter > > > > > Do you have any objection to simply maintaining an updated version > > > of ./configure in CVS? > > > > My experience shows, that this does not work well. It would mean > > committing all the autotools generated files to CVS (aclocal.m4, all > > Makefile.in, etc.). Since autotools uses timestamps to trigger rebuilding > > of its own meta files (e.g. when you edit a Makefile.am, when you change > > configure.ac,...), the freshly checked out CVS distribution tends to want > > to rebuild parts because of confused timestamps. This forces you to have > > a matching version of autotools on your system anyways. > > > > I propose that I install a little bootstrap script that runs the > > libtoolize, aclocal,automake,autoconf commands for convenience. You just > > loose a few seconds for the bootstrap procedure (but sure. You need to > > have the autotools installed). > > > > Building for a non developer should always be done from a generated > > tarball (and this is the portable way to do it). > > > > There is a maintainer mode option in autotools which prevents rebuilding > > of the automake generated files, but it makes work more complicated. > > > > Cheers, > > Derek > > > > On Tuesday 11 October 2005 19.13, Peter Elmer wrote: > > > Hi Derek, > > > > > > Do you have any objection to simply maintaining an updated version > > > of ./configure in CVS? Although it is not quite as "from source" > > > as using the autotools to build it from scratch each time one checks > > > out from CVS, it would simplify things for most developers most of the > > > time. We just need to make sure it is updated when somebody makes > > > changes which require it to be updated. > > > > > > Pete > > > > > > On Tue, Oct 11, 2005 at 11:47:16AM +0200, Derek Feichtinger wrote: > > > > Ciao, Fabrizio > > > > > > > > This is what I mentioned in my first migration mail to the list. You > > > > need reasonably new versions of the autotools (libtool should be very > > > > new to correctly produce files which work on Macs). > > > > > > > > ------------------------------ > > > > > > > > > To use the new autotools build: > > > > > You should install automake > 1.6, autoconf-2.59 and libtool 1.5.18 > > > > > on your system. > > > > > > > > ------------------------------- > > > > > > > > Best you get them as tarballs from the GNU site. They build very fast > > > > (first get Autoconf, then Automake and then libtool). The Solaris > > > > machines at SLAC seem to have really ancient versions which have been > > > > out of use for several years (early versions of Autoconf required a > > > > configure.in file. Now this has been renamed configure.ac to prevent > > > > confusion with the files on which configure acts, which are all named > > > > *.in) > > > > > > > > Cheers, > > > > Derek > > > > > > > > On Tuesday 11 October 2005 11.34, you wrote: > > > > > Hi, thank you. > > > > > > > > > > One more question. Is there anything special I have to do to work > > > > > under Solaris? > > > > > For instance, aclocal fails on shire02 at slac from a fresh > > > > > checkout, it says that it needs a configure.in file. From a Linux > > > > > machine (noric02) instead it works fine. > > > > > > > > > > Any hint? > > > > > > > > > > > > > > > Fabrizio > > > > > > > > > > Derek Feichtinger wrote: > > > > > > Hi, Fabrizio > > > > > > > > > > > > Take a look at the Makefile.am in the XrdClient directory: > > > > > > > > > > > > If you want to recourse into subdirectories, you just add a > > > > > > > > > > > > SUBDIRS = dir1 dir2 dir3 > > > > > > > > > > > > statement. > > > > > > > > > > > > Build targets in automake are specified via directives like > > > > > > > > > > > > bin_PROGRAMS = myprogram1 myprogram2 > > > > > > > > > > > > The prefix (bin) defines where the file will be installed, the > > > > > > type (PROGRAM) defines what kind of targets should be built. > > > > > > > > > > > > There is a special prefix "check". This specifies targets that > > > > > > will never be installed and that get only built when a "make > > > > > > check" is given. This is specially designed for tests that are > > > > > > run after the initial build to check the package's sanity. > > > > > > The variable TESTS hold the name of the tests to be run. > > > > > > > > > > > > "Info Automake" should provide you with quite some information as > > > > > > well as the autobook (chapter 7.7): > > > > > > http://sources.redhat.com/autobook/autobook/autobook_toc.html > > > > > > > > > > > > I can gladly help you to get started if you have specific > > > > > > questions. > > > > > > > > > > > > Cheers, > > > > > > Derek > > > > > > > > > > > > On Tuesday 11 October 2005 10.35, Fabrizio Furano wrote: > > > > > >>Hi, > > > > > >> > > > > > >> just for the records, is there anything special I have to do if > > > > > >> I want to add new files/dirs to XrdClient with the new building > > > > > >> scheme? > > > > > >> > > > > > >> If everything goes well, in the next period I'd like to add > > > > > >> some modules and a directory containing test programs. How do I > > > > > >> do that? > > > > > >> > > > > > >>Fabrizio > > > > > >> > > > > > >>Derek Feichtinger wrote: > > > > > >>>I forgot: > > > > > >>> > > > > > >>>to reduce the current compilation output, type > > > > > >>> > > > > > >>>make silent > > > > > >>> > > > > > >>>(just filters the compilation lines with sed, stderr still > > > > > >>> visible). At some point one could introduce a config.h file, > > > > > >>> which is used to pass all the compile switches determined by > > > > > >>> configure to the preprocessor, so the awfully long compile > > > > > >>> lines would get shorter. But this requires adding a include > > > > > >>> directive to all source files, so I did not want to do it now. > > > > > >>> > > > > > >>>To build the test files (e.g. for crypto and mon stuff) > > > > > >>> > > > > > >>>make check > > > > > >>> > > > > > >>>They will never be installed by make install (the check target > > > > > >>> is just for compiling and running a package's tests. At some > > > > > >>> point one could add some active tests to this target). > > > > > >>> > > > > > >>> > > > > > >>>make distcheck > > > > > >>> > > > > > >>>this will ensure, that a generated tarball can indeed compile. > > > > > >>> > > > > > >>>Cheers, > > > > > >>>Derek > > > > > > > > -- > > > > Dr. Derek Feichtinger Tel: +41 22 767 10 07 > > > > LCG/ARDA Group email: > > > > [log in to unmask] CERN > > > > http://people.web.psi.ch/feichtinger CH-1211 Genève 23 > > > > > > ----------------------------------------------------------------------- > > >-- Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) > > > 767-4644 Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, > > > Switzerland > > > ----------------------------------------------------------------------- > > >-- -- Dr. Derek Feichtinger Tel: +41 22 767 10 07 LCG/ARDA Group email: [log in to unmask] CERN http://people.web.psi.ch/feichtinger CH-1211 Genève 23