[news.eclipse.technology.linuxtools] Re: Using autoheader and libtoolize

[Lorenzo Bettini <bettini@xxxxxxxxxxxx>]

Jeff Johnston wrote:
> Lorenzo Bettini wrote:
>
> > Jeff Johnston wrote:
> > > Lorenzo Bettini wrote:
> > >
> > > > Jeff Johnston wrote:
> > > > > Lorenzo Bettini wrote:
> > > > >
> > > > > > Jeff Johnston wrote:
> > > > > > > Matthias Jeschke wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > >
> > > > > > > > I'am currently working on a project that uses autotools and as 
> > > > > > > > I'am used to eclipse I want import this project as a C++ 
> > > > > > > > autotools project. Everything works fine, except that for 
> > > > > > > > building the project autoheader and libtoolize must be called to 
> > > > > > > > create the appropriate config.h.in etc.
> > > > > > >
> > > > > > > > What would be the best way to call autoheader and libtoolize 
> > > > > > > > from within eclipse? Is there a way to add these calls to 
> > > > > > > > autogen.sh?
> > > > > > >
> > > > > > > Matthias,
> > > > > > >
> > > > > > > The current Autotools plugin doesn't currently support direct 
> > > > > > > calling of autoheader and libtoolize as it does for autoconf, 
> > > > > > > automake, and aclocal, but as you have correctly guessed, you can 
> > > > > > > place these calls into an autogen.sh script which is run as part 
> > > > > > > of the Autotools configuration step.  Autotools expects that 
> > > > > > > autogen.sh is only run once and that configure will be created as 
> > > > > > > part of the autogen.sh invocation so it does not run autogen.sh 
> > > > > > > if configure already exists in the build directory.
> > > > > > >
> > > > > > > Feel free to open RFEs to add UI support to Autotools for calling 
> > > > > > > autoheader and libtoolize if you want to track the addition of 
> > > > > > > those features.
> > > > >
> > > > > > Hi
> > > > >
> > > > > > why does it use (and expect) autogen.sh, instead of relying on 
> > > > > > autoreconf?
> > > > >
> > > > > > cheers
> > > > > >     Lorenzo
> > > > >
> > > > > It does not "expect" autogen.sh, it simply looks for it as some 
> > > > > projects choose to not ship generated files and use autogen.sh to 
> > > > > set the project up initially.  autoreconf is only useful after you 
> > > > > have done an initial generation because it only remakes those files 
> > > > > that are older than their sources and it wouldn't know what options 
> > > > > to use unless the file had at least been generated once.
> > >
> > > > Mh, well that's not exactly true: you can bootstrap an autotools 
> > > > project by issuing
> > >
> > > > autoreconf -i
> > >
> > > > (with -s missing files will soft linked), and the automake manual says:
> > >
> > > > "Many packages come with a script called bootstrap.sh or autogen.sh, 
> > > > that will just call aclocal, libtoolize, gettextize or autopoint, 
> > > > autoconf, autoheader, and automake in the right order. Actually this 
> > > > is precisely what autoreconf can do for you. If your package has 
> > > > such a bootstrap.sh or autogen.sh script, consider using autoreconf. 
> > > > That should simplify its logic a lot (less things to maintain, 
> > > > yum!), it's even likely you will not need the script anymore, and 
> > > > more to the point you will not call aclocal directly anymore. "
> > >
> > > > just my two cents :-)
> > >
> > > To clarify, how do you know about options (e.g. if --cygnus is to be 
> > > used when calling automake or aclocal requires a -I ../.. to work as 
> > > needed) if none of the files have yet been generated?  This 
> > > information is stored after the first time it is run.  If all you 
> > > need is vanilla calls, then yes, there is no problem.
> > > I am in full agreement that autoreconf support should be added.
>
> > You can set it in your root Makefile.am, e.g.,
>
> > ACLOCAL_AMFLAGS = -I m4 -I gl/m4
>
> > and for automake arguments, you can set it in configure.ac, e.g.,:
>
> > AM_INIT_AUTOMAKE([-Wall -Werror foreign])
>
> > I've been using autogen.sh before, but then I switched to autoreconf 
> > and always use that without problems :-)
>
> I had forgotten about AM_INIT_AUTOMAKE.
>
> Anyway, I am not arguing about adding autoheader support, just that the 
> search for autogen.sh in the current logic is valid and needs to be 
> kept.  If a project has an autogen.sh file, it should be run.  If it 
> doesn't, then running autoheader is a logical next step as the steps 
> above may or may not have been done.

Right!

Lore

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
ICQ# lbetto, 16080134     (GNU/Linux User # 158233)
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
http://www.myspace.com/supertrouperabba
BLOGS: http://tronprog.blogspot.com  http://longlivemusic.blogspot.com
http://www.gnu.org/software/src-highlite
http://www.gnu.org/software/gengetopt
http://www.gnu.org/software/gengen http://doublecpp.sourceforge.net