From: Christian Holm Christensen (cholm@hehi03.nbi.dk)
Date: Tue Sep 16 2003 - 03:57:38 EDT
Hi Flemming, "Flemming Videbaek" <videbaek@rcf.rhic.bnl.gov> wrote concerning make+autotools in RH8 [Mon, 15 Sep 2003 15:36:21 -0400] ---------------------------------------------------------------------- > > > Some question in regards to the new setup for RH8.0 etc. > > This needs a real expert for autotools - and I am not one; > It may be in the manual but if anyone knows this let us attempt to fix these > # issue described below. As CVS access from nbi.dk is not working properly these days, due to CERN not having updated their cell information (my guess is that RCF has `forgotten' to tell the individual cell administrators), I can not check out any software at the moment, so these comments are un-tested, and hence not necessarily correct. > II brop ****************** > ____ > > The combinations of autotools now produce the following warnings for each > single module compiled > > > source='BrBaseMonitor.cxx' object='BrBaseMonitor.lo' libtool=yes \ > depfile='.deps/BrBaseMonitor.Plo' tmpdepfile='.deps/BrBaseMonitor.TPlo' \ > depmode=gcc3 /bin/sh ../../config/depcomp \ > /bin/sh ../../libtool --mode=compile g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"brop\" -DVERSION=\"1.2.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I. -D_REENTRANT -I/afs/rhic.bnl.gov/opt/brahms/new/include/root -DPACKAGE_NAME= -DPACKAGE_TARNAME= -DPACKAGE_VERSION= -DPACKAGE_STRING= -DPACKAGE_BUGREPORT= -DONL_unix=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 > -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I/home2/home/videbaek/include/brat -g -O2 -c -o BrBaseMonitor.lo `test -f 'BrBaseMonitor.cxx' || echo './'`BrBaseMonitor.cxx > g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"brop\" -DVERSION=\"1.2.1\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I. -D_REENTRANT -I/afs/rhic.bnl.gov/opt/brahms/new/include/root -DPACKAGE_NAME= -DPACKAGE_TARNAME= -DPACKAGE_VERSION= -DPACKAGE_STRING= -DPACKAGE_BUGREPORT= -DONL_unix=1 -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I/home2/home/videbaek/include/brat -g -O2 -c BrBaseMonitor.cxx -MT BrBaseMonitor.lo -MD -MP -MF .deps/BrBaseMonitor.TPlo -fPIC -DPIC -o BrBaseMonitor.lo > <command line>:1:1: warning: "PACKAGE_NAME" redefined > <command line>:1:1: warning: this is the location of the previous definition > <command line>:1:1: warning: "PACKAGE_TARNAME" redefined > <command line>:1:1: warning: this is the location of the previous definition > <command line>:1:1: warning: "PACKAGE_VERSION" redefined > <command line>:1:1: warning: this is the location of the previous definition > <command line>:1:1: warning: "PACKAGE_STRING" redefined > <command line>:1:1: warning: this is the location of the previous definition > <command line>:1:1: warning: "PACKAGE_BUGREPORT" redefined > <command line>:1:1: warning: this is the location of the previous definition It seems that the `CPPFLAGS' Make macro is used several times in the compilation. Please check that Make macros `AM_CPPFLAGS', `INCLUDES', or `DEFS' does not contain a reference to `CPPFLAGS' directly or indirectly. Could you tell me what `brat-config --cppflags' gives you? Thanks. Another work-around would be to use a `config.h' header, and have the relevant source code files (`.cxx') include that header. > Some names seems in fact blank. Where are these supposed to be set. It's because you're using a newer version of Autoconf, which supports setting such stuff as package long name e.g., `BRahms Analysis Toolkit', package short/tar-ball name e.g., `brat', package version number e.g., `2.11.1', and bug-report address e.g., `brahmlib@rhic.bnl.gov'. However, to set these one need to put AC_INIT([BRahms Analysis Toolkit],[2.11.1], [brahmlib@rhic.bnl.gov],[brat]) AC_COPYRIGHT([GNU General Public License]) AC_REVISION($Revision$) AM_INIT_AUTOMAKE([$PACKAGE_TARNAME],[$PACKAGE_VERSION]) into the `configure.in' script. However, _do_not_do_this_yet_, as all of the BRAHMS collaboration institutes have not updated to the newer Autotools tool-chain. This is a consequence of the Autotools-paradigm change mention over and over again. At this point, it might be a good idea to skim through the manuals again :-) > III ------------------------------ > > make -j2 > > As we all know compiling Brat in particular takes long time; Why > can't the Makesystem that we build on top of autotools be run with > make -j2 i.e. utilizing the dual processors. It starts up but seems > always to run into trouble likely when same needed in one brahnch > are being modified by another ?? This has to do with the fact that we build source files i.e., the dictionary files. Try adding the dictionary sources to the variable `BUILT_SOURCES' in each `Makefile.am' that contains these. It's probably a matter of a clever `query-replace-regexp' in Emacs or some (one line?) Perl script. > Could this be used at the lowest level i.e. for compilation step only? Not as it is set up now, no. Note however, that GCC itself is usually parallelising. What we could do, if all institutions had newer Autotools, would be to have a non-recursive build system (much like ROOT, only better :-), which should speed up the build process somewhat, and make it possible to build in parallel. However, that must be put on hold until such a time when every single institution has updated to the newer Autotools tool-chain, as it is not backward compatible (it's a whole new way of doing things!). > I autogen************ (minor issue) > ---------- > > The default autogen has some checks as described. Erh, you mean `The default _configure_ has ...', right? Autogen is just a wrapper for doing libtoolize --automake aclocal automake -a autoconf ./configure > Is this still the proper one i.e. this is for C and has no relavance > for our C++ stuff? > > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes These checks comes from `AC_PROG_LIBTOOL' and is largely redundant, yes. This is being worked on by the upstream `Libtool' maintainers. For now, ignore them, and be assured that these tests are cached from each execution of `./configure'. For those interested, take a look at _any_ of my software available from `http://cholm.home.cern.ch/cholm/misc/'. They all use (almost) bleeding-edge `Autotools'. Note that that is not a problem for the users - they don't even need to have Autotools installed, only for developers, and only if they change something in the build files. Yours, ___ | Christian Holm Christensen |_| | ------------------------------------------------------------- | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _| Denmark Office: (+45) 353 25 404 ____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm | |
This archive was generated by hypermail 2.1.5 : Tue Sep 16 2003 - 03:58:31 EDT