Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Linux Tools Project » Using autoheader and libtoolize
Using autoheader and libtoolize [message #7343] Thu, 26 February 2009 10:53 Go to next message
Matthias Jeschke is currently offline Matthias Jeschke
Messages: 2
Registered: July 2009
Junior Member
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?

Best regards

Matthias Jeschke
Re: Using autoheader and libtoolize [message #7355 is a reply to message #7343] Thu, 26 February 2009 11:47 Go to previous messageGo to next message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

-- Jeff J.
Re: Using autoheader and libtoolize [message #9810 is a reply to message #7355] Fri, 05 June 2009 03:58 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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

--
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
Re: Using autoheader and libtoolize [message #9854 is a reply to message #9810] Mon, 08 June 2009 12:27 Go to previous messageGo to next message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

-- Jeff J.
Re: Using autoheader and libtoolize [message #9878 is a reply to message #9854] Mon, 08 June 2009 12:54 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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 :-)

--
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
Re: Using autoheader and libtoolize [message #9924 is a reply to message #9878] Mon, 08 June 2009 14:01 Go to previous messageGo to next message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.
Re: Using autoheader and libtoolize [message #9948 is a reply to message #9924] Tue, 09 June 2009 04:04 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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 :-)

cheers
Lorenzo

--
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
Re: Using autoheader and libtoolize [message #10085 is a reply to message #9948] Thu, 11 June 2009 12:37 Go to previous messageGo to next message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

-- Jeff J.
Re: Using autoheader and libtoolize [message #10109 is a reply to message #10085] Thu, 11 June 2009 13:54 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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
Re: Using autoheader and libtoolize [message #10131 is a reply to message #10085] Thu, 11 June 2009 14:01 Go to previous messageGo to next message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

I meant autoreconf, not autoheader above :)
Re: Using autoheader and libtoolize [message #10154 is a reply to message #10131] Fri, 12 June 2009 13:11 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
Jeff Johnston wrote:
>> 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.
>
> I meant autoreconf, not autoheader above :)

yes, I had inferred that ;-)

--
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
Re: Using autoheader and libtoolize [message #12241 is a reply to message #10154] Thu, 18 June 2009 14:27 Go to previous messageGo to next message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
Lorenzo Bettini wrote:

> Jeff Johnston wrote:
>>> 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.
>>
>> I meant autoreconf, not autoheader above :)

> yes, I had inferred that ;-)

FYI, I have just added the support into trunk which will be for Galileo.
I also added support for calling autoheader, autoreconf, and libtoolize
directly as is already in place for aclocal, automake, and autoconf.

Thanks for bringing this to light.
Re: Using autoheader and libtoolize [message #12341 is a reply to message #12241] Thu, 02 July 2009 09:52 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
Jeff Johnston wrote:
> Lorenzo Bettini wrote:
>
>> Jeff Johnston wrote:
>>>> 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.
>>>
>>> I meant autoreconf, not autoheader above :)
>
>> yes, I had inferred that ;-)
>
> FYI, I have just added the support into trunk which will be for
> Galileo. I also added support for calling autoheader, autoreconf, and
> libtoolize directly as is already in place for aclocal, automake, and
> autoconf.
> Thanks for bringing this to light.
>

happy to hear that :-)

so which branch should I use to get the latest development release
(which I guess works only for galileo)?

cheers
Lorenzo

--
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
Re: Using autoheader and libtoolize [message #12351 is a reply to message #12341] Mon, 06 July 2009 12:59 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
>> FYI, I have just added the support into trunk which will be for
>> Galileo. I also added support for calling autoheader, autoreconf, and
>> libtoolize directly as is already in place for aclocal, automake, and
>> autoconf.
>> Thanks for bringing this to light.
>>

> happy to hear that :-)

> so which branch should I use to get the latest development release
> (which I guess works only for galileo)?

> cheers
> Lorenzo

The code is in autotools/trunk. It used to be in
autotools/branches/Galileo but that has been moved to trunk and the old
trunk code has been moved to autotools/branches/Ganymede.

The latest code requires Galileo (Eclipse 3.5 and CDT 6).

-- Jeff J.
Re: Using autoheader and libtoolize [message #565785 is a reply to message #7343] Thu, 26 February 2009 11:47 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

-- Jeff J.
Re: Using autoheader and libtoolize [message #566234 is a reply to message #7355] Fri, 05 June 2009 03:58 Go to previous message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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

--
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
Re: Using autoheader and libtoolize [message #566272 is a reply to message #9810] Mon, 08 June 2009 12:27 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

-- Jeff J.
Re: Using autoheader and libtoolize [message #566298 is a reply to message #9854] Mon, 08 June 2009 12:54 Go to previous message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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 :-)

--
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
Re: Using autoheader and libtoolize [message #566358 is a reply to message #9878] Mon, 08 June 2009 14:01 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.
Re: Using autoheader and libtoolize [message #566381 is a reply to message #9924] Tue, 09 June 2009 04:04 Go to previous message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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 :-)

cheers
Lorenzo

--
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
Re: Using autoheader and libtoolize [message #566479 is a reply to message #9948] Thu, 11 June 2009 12:37 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

-- Jeff J.
Re: Using autoheader and libtoolize [message #566503 is a reply to message #10085] Thu, 11 June 2009 13:54 Go to previous message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
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
Re: Using autoheader and libtoolize [message #566528 is a reply to message #10085] Thu, 11 June 2009 14:01 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
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.

I meant autoreconf, not autoheader above :)
Re: Using autoheader and libtoolize [message #566546 is a reply to message #10131] Fri, 12 June 2009 13:11 Go to previous message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
Jeff Johnston wrote:
>> 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.
>
> I meant autoreconf, not autoheader above :)

yes, I had inferred that ;-)

--
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
Re: Using autoheader and libtoolize [message #566601 is a reply to message #10154] Thu, 18 June 2009 14:27 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
Lorenzo Bettini wrote:

> Jeff Johnston wrote:
>>> 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.
>>
>> I meant autoreconf, not autoheader above :)

> yes, I had inferred that ;-)

FYI, I have just added the support into trunk which will be for Galileo.
I also added support for calling autoheader, autoreconf, and libtoolize
directly as is already in place for aclocal, automake, and autoconf.

Thanks for bringing this to light.
Re: Using autoheader and libtoolize [message #566803 is a reply to message #12241] Thu, 02 July 2009 09:52 Go to previous message
Lorenzo Bettini is currently offline Lorenzo Bettini
Messages: 1307
Registered: July 2009
Senior Member
Jeff Johnston wrote:
> Lorenzo Bettini wrote:
>
>> Jeff Johnston wrote:
>>>> 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.
>>>
>>> I meant autoreconf, not autoheader above :)
>
>> yes, I had inferred that ;-)
>
> FYI, I have just added the support into trunk which will be for
> Galileo. I also added support for calling autoheader, autoreconf, and
> libtoolize directly as is already in place for aclocal, automake, and
> autoconf.
> Thanks for bringing this to light.
>

happy to hear that :-)

so which branch should I use to get the latest development release
(which I guess works only for galileo)?

cheers
Lorenzo

--
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
Re: Using autoheader and libtoolize [message #566829 is a reply to message #12341] Mon, 06 July 2009 12:59 Go to previous message
Jeff Johnston is currently offline Jeff Johnston
Messages: 173
Registered: July 2009
Senior Member
>> FYI, I have just added the support into trunk which will be for
>> Galileo. I also added support for calling autoheader, autoreconf, and
>> libtoolize directly as is already in place for aclocal, automake, and
>> autoconf.
>> Thanks for bringing this to light.
>>

> happy to hear that :-)

> so which branch should I use to get the latest development release
> (which I guess works only for galileo)?

> cheers
> Lorenzo

The code is in autotools/trunk. It used to be in
autotools/branches/Galileo but that has been moved to trunk and the old
trunk code has been moved to autotools/branches/Ganymede.

The latest code requires Galileo (Eclipse 3.5 and CDT 6).

-- Jeff J.
Previous Topic:Can't use oprofile anymore
Next Topic:autotools in Galileo?
Goto Forum:
  


Current Time: Wed Jul 30 17:33:07 EDT 2014

Powered by FUDForum. Page generated in 0.06268 seconds