Tutorial for using autoconf and automake?
in [Unix Programming]
|
From: Poster Matt on 7 Apr 2010 12:36 Andrew Poelstra wrote: > On 2010-04-07, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: >> Can anyone suggest a really good tutorial for using autoconf and automake? >> >> I found several, but only one (linked below) made a good effort at explaining >> what each stage was doing and, having worked my way through it, ultimately it >> failed and the tutorial did not help me resolve them nor was I able to work out >> what I needed to do to resolve the errors I was getting. >> >> http://mij.oltrelinux.com/devel/autoconf-automake/ >> >> Here's hoping you guys can point me in the right direction. >> >> Thanks all. > > This might not be helpful, but esr just posted a rant about > autotools last week: http://esr.ibiblio.org/?p=1877 > > The comments in the article suggest using scons instead. > I've taken a quick look through it's documentation, and > it looks a lot easier (and saner) than autotools. > > In any case, good luck! Thanks and I think I'll take a look at scons. I'm not doing well with the autotools. Cheers.
From: William Ahern on 7 Apr 2010 14:31 Poster Matt <postermatt(a)no_spam_for_me.org> wrote: <snip> > Thanks and I think I'll take a look at scons. I'm not doing well with the > autotools. What are you building? Most of my projects use POM, which IMHO is far superior in the common case to scons, autotools, CMake, et al. For one thing, POM has a very simple syntax. In fact, it's so simple that when I begin developing a new project--usually starting w/ a single source file--I don't even need to write any additional "build" code to use POM. It magically knows what I'm trying to do when I invoke the POM utility. POM doesn't get in my way by being overly presumptive. This is nice because I often use pre-processing systems like Ragel or M4. Systems such as scons can, of course, allow this, but code for doing this is nowhere near as obvious, mostly because unlike POM other systems are built on top of general purpose languages, not intended, semantically, to declare build rules per se. This adds an additional layer of needless complexity. POM's syntax, in contrast, is a very straightforward declarative syntax which meshes well w/ the need to employ other languages as the nitty-gritty of transforming source code requires. POM is extremely portable. So portable, in fact, that is has zero dependencies on any POSIX system. I don't need to install Python... or anything, really. When a project gets sufficiently complex that I find that I'm spending too much time worrying about build issues instead of application issues (and this is an extremely low threshold for me), I often turn to GNU POM. GNU POM has a few extra bells & whistles that can make some tasks easier, w/o being overly burdensome in terms of language complexity or in availability on other systems. Now, POM is limited. POM can't wash your dishes or fold your sheets. POM doesn't magically make application portability issues go away, either. CMake, scons, autotools and others _claim_ to make portability issues go away, but experience teaches that they don't really solve the hard portability issues. They solve some easy issues, but the marginal cost (i.e. the fixed cost of POM minus the fixed cost of another system) often exceeds the cost of solving those same issues yourself, or alternatively off-loading to the beneficiary (e.g. a distro packager or ports maintainer), as appropriate. Indeed, some of the most widely portable projects use POM, including qmail and Lua and countless others. These success stories aren't widely spoken of because, well, they're successes. Much like the history of Unix itself, POM achieves a satisfying balance between capability and complexity. In line with the Perl creedo, it makes simple things easy and difficult things possible. To learn more about POM, and assuming you're on a Unix'ish system, simply enter `man make' at the command line. GNU POM has the best documentation and overall introduction to the use of POM in general. On a GNU system such as most Linux installations, simply enter `info make' at your command line.
From: Måns Rullgård on 7 Apr 2010 19:33 Poster Matt <postermatt(a)no_spam_for_me.org> writes: > Can anyone suggest a really good tutorial for using autoconf and automake? > > I found several, but only one (linked below) made a good effort at > explaining what each stage was doing and, having worked my way through > it, ultimately it failed and the tutorial did not help me resolve them > nor was I able to work out what I needed to do to resolve the errors I > was getting. > > http://mij.oltrelinux.com/devel/autoconf-automake/ > > Here's hoping you guys can point me in the right direction. Short version: don't use autoconf/automake. They will cause you more pain and suffering than you can possibly imagine. -- M�ns Rullg�rd mans(a)mansr.com
From: Blikje Ham on 8 Apr 2010 05:31 On 2010-04-07, Poster Matt <postermatt(a)no_spam_for_me.org> wrote: > Umm (small?) problem... > > I've been following this tutorial: > > http://mij.oltrelinux.com/devel/autoconf-automake/ > > I'm at step 7. So I've edited 'configure.ac' and added: > > AM_INIT_AUTOMAKE(testrun, 1.0) > AC_OUTPUT(Makefile src/Makefile) > > Then run 'aclocal' and then: 'automake --add-missing' which generates an error: > > "configure.ac:8: required file `config.h.in' not found" > > Running 'automake' alone with '--add-missing' removed generates the same error. > > Can't seem to get possible answers to this with google. BTW I did change the > name of my source code files config.c and config.h to configfile.c and configfile.h. > > Any ideas? > > Thanks. I use `autoheader` to create the config.h.in. And for `automake --add-missing` you might also want to include the `--copy` option (else it will only symlink to the files missing). I hope this will help.
From: Poster Matt on 8 Apr 2010 07:28 William Ahern wrote: > Poster Matt <postermatt(a)no_spam_for_me.org> wrote: > <snip> >> Thanks and I think I'll take a look at scons. I'm not doing well with the >> autotools. > > What are you building? > > Most of my projects use POM, which IMHO is far superior in the common case > to scons, autotools, CMake, et al. > > For one thing, POM has a very simple syntax. In fact, it's so simple that > when I begin developing a new project--usually starting w/ a single source > file--I don't even need to write any additional "build" code to use POM. It > magically knows what I'm trying to do when I invoke the POM utility. > > POM doesn't get in my way by being overly presumptive. This is nice because > I often use pre-processing systems like Ragel or M4. Systems such as scons > can, of course, allow this, but code for doing this is nowhere near as > obvious, mostly because unlike POM other systems are built on top of general > purpose languages, not intended, semantically, to declare build rules per > se. This adds an additional layer of needless complexity. POM's syntax, in > contrast, is a very straightforward declarative syntax which meshes well w/ > the need to employ other languages as the nitty-gritty of transforming > source code requires. > > POM is extremely portable. So portable, in fact, that is has zero > dependencies on any POSIX system. I don't need to install Python... or > anything, really. > > When a project gets sufficiently complex that I find that I'm spending too > much time worrying about build issues instead of application issues (and > this is an extremely low threshold for me), I often turn to GNU POM. GNU POM > has a few extra bells & whistles that can make some tasks easier, w/o being > overly burdensome in terms of language complexity or in availability on > other systems. > > Now, POM is limited. POM can't wash your dishes or fold your sheets. POM > doesn't magically make application portability issues go away, either. > CMake, scons, autotools and others _claim_ to make portability issues go > away, but experience teaches that they don't really solve the hard > portability issues. They solve some easy issues, but the marginal cost (i.e. > the fixed cost of POM minus the fixed cost of another system) often exceeds > the cost of solving those same issues yourself, or alternatively off-loading > to the beneficiary (e.g. a distro packager or ports maintainer), as > appropriate. Indeed, some of the most widely portable projects use POM, > including qmail and Lua and countless others. These success stories aren't > widely spoken of because, well, they're successes. Much like the history of > Unix itself, POM achieves a satisfying balance between capability and > complexity. In line with the Perl creedo, it makes simple things easy and > difficult things possible. > > To learn more about POM, and assuming you're on a Unix'ish system, simply > enter `man make' at the command line. GNU POM has the best documentation and > overall introduction to the use of POM in general. On a GNU system such as > most Linux installations, simply enter `info make' at your command line. Thanks. I can't seem to find POM anywhere. Your last paragraph instructing me to 'man make' and 'info make' in conjunction with my inability to find GNU POM suggest to me that your post might be an elaborate joke (apologies if not) telling me that I should just stick with 'make'. Please confirm or deny joke status. :)
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Bill Cunningham and sockets for the past six years Next: wait for particular process pid |