<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Sep 7, 2009, at 12:59 PM, Török Edwin wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 2009-09-07 21:46, Shantonu Sen wrote:<br><blockquote type="cite">This patch looks scary to me. Do we really want to invest in moving to<br></blockquote><blockquote type="cite">a new autoconf/libtool/automake version that I'm told has known<br></blockquote><blockquote type="cite">incompatibilities (which means it's unlikely to be used by anyone else)?<br></blockquote><br>I can't regenerate llvm's configure with autoconf 2.61 or autoconf 2.64<br>which are the only ones available on Debian.<br>The regeneration succeeds, but there is a syntax error in configure when<br>run (a libtool macro is not expanded).<br>I'd like to support both autoconf 2.60 and 2.64.<font class="Apple-style-span" color="#000000"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>It's trivial to use whatever version of auto* AutoRegen.sh requires:</div><div><br></div></div><div><div>[ssen@virgon]$ eval `grep ^want_ AutoRegen.sh | grep -v _clean | tr -d '\'`</div><div>[ssen@virgon]$ ( mkdir -p src; cd src; for p in autoconf-${want_autoconf_version} automake-${want_aclocal_version} libtool-${want_libtool_version}; do curl -O <a href="ftp://ftp.gnu.org/pub/gnu">ftp://ftp.gnu.org/pub/gnu</a>/`echo $p | awk -F- '{print $1}'`/$p.tar.gz; tar zxf $p.tar.gz; cd $p; ./configure --prefix=$PWD/../../dst && make && make install; cd ..;  done; cd ..; echo "Now add $PWD/dst/bin to the front of your PATH" )</div><div>...</div><div><div>Now add /Volumes/HD/ltmp/ssen/llvm/autoconf/dst/bin to the front of your PATH</div></div><div><div>[ssen@virgon]$ export PATH=/Volumes/HD/ltmp/ssen/llvm/autoconf/dst/bin:$PATH</div><div>[ssen@virgon]$ ./AutoRegen.sh </div><div>...</div><div><br></div><div>Every Linux distribution, Mac OS X install, FreeBSD, etc., has a different combination of auto*/libtool versions. LLVM has standardized on some versions of those tools, and developers should match.</div><div><br></div><div>I don't think AutoRegen.sh should support ranges of tools, because it makes incremental changes to ./configure meaningless because every line will change. If it's autoconf-2.64, I think that should be what AutoRegen.sh requires, even if configure.ac accepts a lower version for local quick-fix development.</div><div><br></div><div>I'm confused about libtool requirements. When I try reconfiguring with AutoRegen.sh, the resulting ./configure script has:</div><div><div>checking whether we are using the GNU C++ compiler... yes</div><div>checking whether g++ accepts -g... yes</div><div>../configure: line 5741: LT_PATH_NM: command not found</div><div>checking for GNU make... make</div><div>checking whether ln -s works... yes</div><div><br></div><div>So is libtool required? If it is, please restore it's requirements to AutoRegen.sh, even if ltmain.sh is not used at build time.</div><div><br></div><div><br></div></div></div><br><blockquote type="cite"><div>Thanks for the review, comments below and new patch attached.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Some specific issues:<br></blockquote><blockquote type="cite">1)<br></blockquote><blockquote type="cite"><blockquote type="cite"> dnl Indicate that we require autoconf 2.59 or later. Ths is needed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">because we<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> dnl use some autoconf macros only available in 2.59.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-AC_PREREQ(2.59)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">+AC_PREREQ(2.64)<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Please update the comments<br></blockquote><br>Sorry that should be AC_PREREQ(2.60), it should still work with autoconf<br>2.60.<br>I changed AutoRegen.sh to accept both. If you have autoconf 2.60 can you<br>try whether ./AutoRegen.sh works for you with my patch applied?<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">2)<br></blockquote><blockquote type="cite"><blockquote type="cite">-want_libtool_version='1\.5\.22'<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">What version of libtool is being used? I can't figure it out. Where is<br></blockquote><blockquote type="cite">it documented?<br></blockquote><br>In the newly attached I kept libtool at what LLVM currently has, only<br>one macro is used from it though, see below: AC_PROG_NM.<br>As such I don't think libtool needs to be upgraded.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">3)<br></blockquote><blockquote type="cite"><blockquote type="cite">  3. Copy <SRC>/ltdl.m4 to llvm/autoconf/m4<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">+ 3. Copy <SRC>/ltsugar.m4 to llvm/autoconf/m4<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">  4. Copy <PFX>/share/aclocal/libtool.m4 to llvm/autoconf/m4/libtool.m4<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">You didn't update any of the step numbering, leading to many duplicate<br></blockquote><blockquote type="cite">numbered steps and gaps of steps.<br></blockquote><br>Dropped this section from README now, libtool doesn't need to be updated<br>since we don't use libtool per se.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">4) I thought the policy was not to upgrade config.guess? Even if not,<br></blockquote><blockquote type="cite">you've lost several local LLVM changes:<br></blockquote><blockquote type="cite"><blockquote type="cite">     *:Darwin:*:*)<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">        UNAME_PROCESSOR=`uname -p` || UNAME_PROCESSOR=unknown<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">        case $UNAME_PROCESSOR in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">-           *86) UNAME_PROCESSOR=i686 ;;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">            unknown) UNAME_PROCESSOR=powerpc ;;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">        esac<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I don't know what else was overwritten, but it can't be good.<br></blockquote><br>Didn't know it had LLVM local changes, I'll remove the config.* updates<br>from my patch, and keep them as is.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">6) These changes use libtool internal macros, like<br></blockquote><blockquote type="cite">"_LT_PROG_ECHO_BACKSLASH". These are not stable, and should not be<br></blockquote><blockquote type="cite">used by configure scripts.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I think this requirements more refinement.<br></blockquote><br>Yeah that is hackish, I've done it like that to cut down configure size.<br>However libtool is currently only used to detect the extension of shared<br>libraries, and for AC_PROG_NM.<br>Detecting the shared lib extension with libtool needs LT_INIT that adds<br>another 300K bloat to configure, instead my latest patch determines<br>the  shared lib extension with a much simpler m4 macro I copied from<br>LLVM's libtool.m4.<br><br>I think the libtool.m4 in LLVM allows that, it only has this copyright:<br><br>## Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005<br>## Free Software Foundation, Inc.<br>## Originally by Gordon Matzigkeit <<a href="mailto:gord@gnu.ai.mit.edu">gord@gnu.ai.mit.edu</a>>, 1996<br>##<br>## This file is free software; the Free Software Foundation gives<br>## unlimited permission to copy and/or distribute it, with or without<br>## modifications, as long as this notice is preserved.<br><br>full.patch.gz:<br> autoconf/depcomp                  |  522<br> autoconf/ltmain.sh                | 6863 -------<br> autoconf/m4/bison.m4              |   15<br> autoconf/m4/cxx_bidi_iterator.m4  |   22<br> autoconf/m4/cxx_fwd_iterator.m4   |   22<br> autoconf/m4/cxx_namespaces.m4     |   19<br> autoconf/m4/cxx_std_iterator.m4   |   26<br> autoconf/m4/flex.m4               |   17<br> autoconf/m4/ltdl.m4               |  418<br> autoconf/missing                  |  353<br> b/autoconf/AutoRegen.sh           |   10<br> b/autoconf/README.TXT             |   35<br> b/autoconf/configure.ac           |   40<br> b/autoconf/install-sh             |  530<br> b/autoconf/m4/path_tclsh.m4       |    4<br> b/autoconf/m4/shrext.m4           |   38<br> b/autoconf/mkinstalldirs          |   40<br> b/configure                       |32893<br>++++----------------------------------<br> b/include/llvm/Config/config.h.in |  168<br> 19 files changed, 4522 insertions(+), 37513 deletions(-)<br><br><br>Best regards,<br>--Edwin<br><span><0001-Update-configure.ac-to-work-with-autoconf-2.64.patch></span><span><0003-Update-install-sh-and-mkinstalldirs.patch></span><span><0002-Remove-obsolete-m4-macros-and-unused-programs.-Also-.patch.gz></span><span><0004-Regenerate-configure-and-config.h.in.patch.gz></span><span><full.patch.gz></span></div></blockquote></div><br></body></html>