Home » Eclipse Projects » Linux Tools Project » Using autoheader and libtoolize
| |
| Re: Using autoheader and libtoolize [message #9810 is a reply to message #7355] |
Fri, 05 June 2009 07:58   |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #9854 is a reply to message #9810] |
Mon, 08 June 2009 16:27 |
 Jeff Johnston
Messages: 215
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 16:54 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #9924 is a reply to message #9878] |
Mon, 08 June 2009 18:01 |
Jeff Johnston
Messages: 215
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 08:04 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #10085 is a reply to message #9948] |
Thu, 11 June 2009 16:37 |
Jeff Johnston
Messages: 215
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 17:54 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #10131 is a reply to message #10085] |
Thu, 11 June 2009 18:01 |
Jeff Johnston
Messages: 215
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 17:11 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #12241 is a reply to message #10154] |
Thu, 18 June 2009 18:27 |
Jeff Johnston
Messages: 215
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 13:52 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| | |
| Re: Using autoheader and libtoolize [message #566234 is a reply to message #7355] |
Fri, 05 June 2009 07:58 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #566272 is a reply to message #9810] |
Mon, 08 June 2009 16:27 |
Jeff Johnston
Messages: 215
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 16:54 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #566358 is a reply to message #9878] |
Mon, 08 June 2009 18:01 |
Jeff Johnston
Messages: 215
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 08:04 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #566479 is a reply to message #9948] |
Thu, 11 June 2009 16:37 |
Jeff Johnston
Messages: 215
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 17:54 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #566528 is a reply to message #10085] |
Thu, 11 June 2009 18:01 |
Jeff Johnston
Messages: 215
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 17:11 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Using autoheader and libtoolize [message #566601 is a reply to message #10154] |
Thu, 18 June 2009 18:27 |
Jeff Johnston
Messages: 215
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 13:52 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 01:51:19 GMT 2024
Powered by FUDForum. Page generated in 0.03338 seconds |
] 
Search
Help
Register
Login
Home
