Autotools Mythbuster
autotools.io
Autotools Mythbuster
1–10 of 88 posts
Re: Autotools Mythbuster
#2One 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
Re: Autotools Mythbuster
#3Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.
Re: Autotools Mythbuster
#4One 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.
Re: Autotools Mythbuster
#5One 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
[deleted]
Re: Autotools Mythbuster
#6One 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.
I don't know Autotools, but I find the CMake workflow to be tolerable. Can someone who knows both provide a comparison?
Re: Autotools Mythbuster
#7While 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.
Re: Autotools Mythbuster
#8Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.
Well, is that really fair? autotools' scope is great, like you concede. But it was designed around 1991, right?
> That everyone else just kind of seemed to go with it
There was nothing else better available, and this was effective -- is effective.
If you haven't seen the effect of momentum in software, then this is nothing. Look at how x86 systems get bootstrapped; look at how we interact with important platform devices like the RTC (I/O ports). Virtually none of this has changed because it doesn't introduce significant limitations in operating systems or hardware but it's downright odd.
Re: Autotools Mythbuster
#9Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.
cmake is pretty bad, too, though at least it runs on Windows. (And I don't think it's got quite the same goals as Autotools, though their scopes overlap in many respects.)
I've never met anything build-related, scope large or small, that wasn't somewhere between "PHP" (horrid, workable if you're careful, will rot your brain in the long run) and "Cthulhu" (beyond evil, insofar as normal human modes of comprehension can be said to apply).
I wonder if this is some kind of, like, Heart of Darkness shit.
Re: Autotools Mythbuster
#10Learning about autotools is an amazing source of fremdscham. The whole compilation/packaging stuff is hard to get right but autotools looks like someone completely gave up on producing a good, decent or even bad solution and just tried whatever didn't completely and utterly fail at the task. That everyone else just kind of seemed to go with it... there are just no words to describe how embarrassing that looks.
The big problem is that no one did a better solution. All alternatives are missing one or more crucial features of the autotools (most prominent being portability). And that is sad as well.