Hi Flemming et al, Since some of you are likely to see this behaviour too, I send the message to the list. Flemmings full mail is at the beginning, my answer follows. On Tue, 02 Oct 2001 13:54:25 -0400 Flemming Videbaek <videbaek@sgs1.hirg.bnl.gov> wrote concerning "aclocal and root.m4": > Hi, Christian > > I think this is for you. Thanks for the reply to the other message. > Doe you how a clue to the following mystery ? ( there are cluse at > the end - do not despair) > > I first got this in local copy but then I get it too on a fresh copy > This only happens on rcas - but not on pii's; Is there any default > places where the aclocal goes looking apart from the local > directories This did not happen last week. > > cvs co brat > cd brat > videbaek@rcas0007:/brahms/data01/scratch/fv/brat> aclocal -I config > aclocal: config/root.m4: 7: duplicated macro `AC_ROOT' > aclocal: config/xpm.m4: 6: duplicated macro `AM_PATH_XPM' > > ** why duplicate macro.. > > videbaek@rcas0007:/brahms/data01/scratch/fv/brat> > automake -a > automake: configure.in: installing `config/install-sh' > automake: configure.in: installing `config/mkinstalldirs' > automake: configure.in: installing `config/missing' > configure.in: 74: required file `config/ltconfig' not found > help/Makefile.am:18: installing `help/elisp-comp' > doc/guide/Makefile.am:9: HAS_LTX2H does not appear in AM_CONDITIONAL > doc/guide/Makefile.am:14: HAS_LTX does not appear in AM_CONDITIONAL > doc/guide/Makefile.am:19: HAS_FIG does not appear in AM_CONDITIONAL > doc/guide/Makefile.am:24: HAS_IDX does not appear in AM_CONDITIONAL > doc/guide/Makefile.am:100: HAS_FIG does not appear in AM_CONDITIONAL > doc/guide/Makefile.am:103: HAS_IDX does not appear in AM_CONDITIONAL > > autoconf: Undefined macros: > configure.in:112:AC_DEBUG > configure.in:113:AC_OPTIMIZE > configure.in:73:AC_DISABLE_STATIC > configure.in:79:AC_ROOT > configure.in:84:AC_LATEX > configure.in:85:AC_LATEX2HTML > configure.in:86:AC_DVIPS > configure.in:87:AC_MAKEINDEX > configure.in:88:AC_FIG2DEV > > I did notice you added brat.m4 xpm.m4 root.m4 into > > /afs/rhic/opt/brahms/pro/share > > Is this the intention to move out of reach for changing for people ? > Once I mv the local root.m4 and xpm.m4 out of the way everything is > handy. > > Since some machine use the aclocal from /usr/bin it seem a mistake to > me to have the root.m4 and xpm.m4 in the opt/share/.. > > comments ? Yep, here we go (this is long, but not too long :-) The root (he :-) of this behaviour is the following: On the rcas, and other RCF machines, we use the Autotools installed in /afs/rhic/opt/brahms/pro, since RCF is not very good (sigh) at maintaining proper development platforms [1]. In particular is Libtool _not_ installed on the systems. So we installed our own. Now, aclocal will look for Autoconf macros in <prefix>/share/aclocal where <prefix> is the installation prefix of Autoconf. It is customary for development software packages to install macro file(s) into that directory, so that the package comes with full development support for user software or other software packages. Hence, BRAT installs brat.m4, root.m4, and xpm.m4 (the last two being 'missing' from the upstream supplier) into <prefix>/share/aclocal, where <prefix> is the BRAT installation prefix. I recently installed BRAT with prefix /afs/rhic/opt/brahms/pro, that is the same prefix as Autoconf is installed in. This makes good sense: Since everything lives under one tree, one needs minimal user setup. In fact, you only need to include /afs/rhic/opt/brahms/pro/bin in your PATH [2]. However, root.m4 and xpm.m4 are also present in the config subdirectory of the BRAT source tree. There's, again, good reason for this: If you can not install root.m4 and xpm.m4 into the regular search path of aclocal (you may not have access to those directories), they are provided in that subdirectory. The result of having root.m4 and xpm.m4 in both <prefix>/share/aclocal and config when doing aclocal -I config, is that aclocal findes two, possibly contradictory, definitions of the macros AC_XPM and AC_ROOT, and hence gives up. Just doing aclocal will not solve the problem, since there are other macros defined in files in config that is needed, such as AC_DEBUG, AC_OPTIMIZE, and so on. Moving the files root.m4 and xpm.m4 out of config, does, as Flemming observed, solve the problem. Now, on the pii's we use the Autotools that lives in the system [3] but we do not install BRAT with <prefix>=/usr - even though we could for the production version - and so root.m4 and xpm.m4 is not installed in the aclocal default search path. Hence, the problem never arises. It seems that a number of non-BNL users are installing BRAT with <prefix>=/usr/local. You should _not_ see this problem, since /usr/local/share/aclocal is normally not in the aclocal search path [4]. Some probably installs BRAT with <prefix>=${HOME}. They should have no trouble either unless ofcourse Autoconf is also installed in ${HOME}. Flemming ask is the intention of installing root.m4, xpm.m4, brat.m4, and similar macro files from other packages, is to discourage changes. No, that is not the intention. The intention is that it should be easy for other packages that depend on BRAT (and similar), like BROP to configure the source tree, by using the macros from the BRAT distribution, hence keeping everything easily in sync. Flemming feels that having <...>.m4 in /afs/rhic/opt/brahms/pro/share/aclocal is bad, since some machines has /usr/share/aclocal as there standard macro path. Well, I both agree and not. I agree, because I believe all software should be installed into there regular system tree (/usr or /usr/local) rather than in specific trees (/afs/rhic/opt/brahms), and preferably via the, possibly, avaliable package management software (rpm, dpkg, etc.) [5]. I disagree, since having to have specific trees, the <...>.m4 files really belong to the in those trees - BRAT is installed in /afs/rhic/..., not /usr. All that said, I do agree that it's rather ugly, that one has to move the root.m4 and xpm.m4 out of the way. Ideas for solutions: The long term (read: will not be tomorrow) solution: ROOT and Xpm gets a proper macro file and installs it in <prefix>/share/aclocal. Well, since I wrote the aclocal file that is currently in ROOT, and also the installation stuff, I will at some point make that happen. I seriously doubt that Xpm is going to deliver a macro file on all platforms (witness the Xpm headers on Solaris [1]), so the solution is to either not install it from BRAT (it's not really up to BRAT to install that file in the first place), or to write the macro directly into the configure.in file(s), which basically amounts to the same thing. A similar to the above solution could also work for ROOT, but then we loose the flexibility that we can copy root.m4 to where ever needed. The medium term (read: I'll do at some point, but not tomorrow) solution: Make another directory that contains the "odd" aclocal macros, like say config/misc, and then one will have to run aclocal like aclocal -I config -I config/misc on machines that doesn't have root.m4 and xpm.m4 in the aclocal default search directory. The short term (read: What we do for now) solution: Ask people to move config/root.m4 and config/xpm.m4 out of the way, by for example renaming them to config/root.m4.odd and config/xpm.m4.odd, if aclocal complains about multiple defitiontions. Other teams have done things in other ways (c.f. GNOME), but I really haven't seen a good solution other than each package providing a macro file for it self. It's even worse when you have bootstrapping [6] :-{ Hope that clearifies things. Now I'm tired and I'm going home! Yours, Christian Holm Christensen ------------------------------------------- Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 DK-2200 Copenhagen N Cell: (+45) 28 82 16 23 Denmark Office: (+45) 353 25 305 Email: cholm@nbi.dk Web: www.nbi.dk/~cholm [1] To me, a proper development platform, _must_ have the following tools installed: ANSI/ISO C, C++, and Fortran77 (sigh) compilers (GCC preferably) A good stable debugger like GDB System linker (should support dynamic linking) Automake, Autoconf and Libtool Recent GNU Make (or fully compatible) Sed, Grep, (G)Awk, Tar, Gzip, Bzip2, Bash, Perl, M4 Emacs, vi, CVS Online documentation of all of the above (preferable in info) Also, ANSI header files for all reasonably widely used libraries. For some reason, Solaris has this funny notion that the Xpm header files needn't be ANSI C compliant! Also, the sed, make, and tar deliverd by Sun on Solaris are bad. Shortly - Solaris stinks as a development platform! (ducking my head while angry Solaris-biggots are throwing bad language at me). And to all the Windoze-biggots: notice the complete lack of stupid IDE's like Visual BASIC and so on - not needed, and a bloody wast of time! It's funny to note that Redhat (sigh) does not install Libtool per default when selecting the "development" option (at least it didn't in 6.2), while Debian ofcourse does. Further, one should also expect the SysOp to install libraries and headers that interact with the system, or is widely used on the system. In the case of RCF, that includes MySQL Client libraries (shared) and headers Freetype libraries (shared) and headers OpenGL libraries (shared) and headers CERNLIB libraries (shared) _and_ headers AFS development libraries (static unfortunately) and headers ... [2] Suppose we'd installed our software with the following prefixes: Package: Prefix: -------------------------------------------------- M4 /afs/rhic/opt/brahms/m4/pro Gawk /afs/rhic/opt/brahms/gawk/pro Autoconf /afs/rhic/opt/brahms/autoconf/pro Automake /afs/rhic/opt/brahms/automake/pro Libtool /afs/rhic/opt/brahms/libtool/pro MySQL /afs/rhic/opt/brahms/mysql/pro ROOT /afs/rhic/opt/brahms/root/pro BRAG /afs/rhic/opt/brahms/brag/pro BRAT /afs/rhic/opt/brahms/brat/pro BREG /afs/rhic/opt/brahms/breg/pro BROP /afs/rhic/opt/brahms/brop/pro CRASH /afs/rhic/opt/brahms/crash/pro ... ... [you get the point!] You'd quickly have a PATH that could reach from here (CPH) to BNL, and an even longer LD_LIBRARY_PATH :-( [3] We (really it's Betty, but you get the point) control the pii's so we can make sure those machines are sound development platforms. [4] To see the normal search path of your aclocal, do aclocal --print-ac-dir [5] It shouldn't be too hard to make a BRAT rpm or deb package :-) Any volenteers? [6] You know, trying to lift oneself by ones boots. I believe Baron von Munchausen (the world greatest ... er ... liar) ones saved himself (and his horse) from sinking in a swamp by lifting himself by the collar, and thereby lifted himself and the horse out of the swamp and certain death. Truely, physics was different back then.
This archive was generated by hypermail 2b30 : Tue Oct 02 2001 - 18:54:31 EDT