Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Autotools Mythbuster

autotools.io

Post reply on HN
Print view View original

21–30 of 88 posts

Re: Autotools Mythbuster

#21

Post by wyldfire »

riffraff wrote: post #11
falcolas wrote: post #7

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

there _is_ a huge amount of smart folks who worked or works on build systems. Sadly, it seems everyone is 80% better than the others in something and 20% lacking in something else. For example, the SCons wiki has some interesting comparisons. https://bitbucket.org/scons/scons/wiki/SconsVsOtherBuildTool...

I really liked SCons, but it seems like it never really hit critical mass.

Ubiquity is important for a build tool.

Re: Autotools Mythbuster

#22

Post by rdtsc »

falcolas wrote: post #7

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

The problem is most people who end up using autotools and other build/install/package tools are not interested in their internals or interested in working on them. They just want a tool that gets their job done and they get to do something else.

I realized this a while back, when I was advocating git at my company (maybe 5 or so years back...) some developers loved because they like the idea of it, they wanted to know how it works underneath etc., other group didn't care, didn't want to hear about internal they just wanted a list of commands to type to get their code committed.

Neither one is wrong or or bad, it just comes down to personalities or interests. Autotools is a bit in the same area.

A lot of people will complain about it, because they want to use it to get stuff done. But they will never the ones to start writing tools like it, because they do something else -- databases, graphics, numerical simulations etc.

So "start working on a successor if you don't like it" might not have the same effect for this project.

Re: Autotools Mythbuster

#23

Post by pjmlp »

falcolas wrote: post #7

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

For me it is called cmake.

Re: Autotools Mythbuster

#24

Post by pcwalton »

davexunit wrote: post #4
raverbashing wrote: post #2

One of the first lines "...the language used to write the configure.ac is called M4sh, to make clear that it's based off both sh and the macro language M4. " Tip: don't use Autotools

The Autotools are better than every other supposedly better solution. I do a lot of distro packaging work, and I can say, without a doubt, that the most problematic software to package are the ones that don't use the autotools.

> The Autotools are better than every other supposedly better solution.

... as long as you don't care about Windows (or iOS, or Android, etc.)

Re: Autotools Mythbuster

#25

Post by MichaelMoser123 »

GNU make has macros too, but these were added much later than 1991; Interesting if make macros were available earlier, would people have used them instead of autotools ?

Thank you for the link on autotools, i will try to apply it if i am ever forced to do something with autoconf/autotools.

Re: Autotools Mythbuster

#26

Post by mwcampbell »

falcolas wrote: post #7

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

> as easy for the end user to use as autotools

End-users don't build from source in the first place. At least, if they do, then the developers and/or packagers have failed to do their job.

Re: Autotools Mythbuster

#27

Post by zuzun »

If you want to get started with autotools, try to build yourself a minimal autotools project. Once you have a working stub, you already took the biggest hurdle.

You only need to focus on two files: configure.ac, where you check for features, and Makefile.am, where you list your build targets and their sources. You can also write normal Makefile rules there.

After editing these files, run `autreconf -fi` to create/update the configure and Makefile script. Then run

    ./configure
    make
to build your project. Have a look at Appendix A/Basic Autotoolization on the submitted website or checkout libabc by Poettering/Sievers:

1. https://autotools.io/whosafraid.html#idm117385102076160

2. http://0pointer.de/blog/projects/libabc.html

Re: Autotools Mythbuster

#28

Post by mwcampbell »

rwmj wrote: post #13
falcolas wrote: post #7

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

Of course there are many alternatives (of the alternatives, I can only really recommend cmake). The problems broadly speaking are: * Assumptions: autotools assumes that only a basic Bourne shell is available, and a basic make, and that make is a good way to build projects. All of those are questionable, and certainly if you get rid of the assumption that you're only allowed to use ancient tools, you could immediately…

Do you have any opinion on GYP, as used by Node.js and (last time I checked) Chromium? It seems to be particularly good at producing a large binary made up of a complex graph of static libraries.

Re: Autotools Mythbuster

#30

Post by kazinator »

falcolas wrote: post #7

While it's quite popular to bash autotools, how about instead working towards a successor? One that's as easy for the end user to use as autotools, but with less technical debit. It's a hard problem, as evidenced by the inherent complexity in autotools, but there are a lot of smart folks who could apply their effort towards that goal.

I recommend a hand-crafted configure script, which provides the same usage interface to package builders, without Autocrap:

E.g.:

http://www.kylheku.com/cgit/txr/tree/configure

Post reply on HN