>i dont see how blaming autotools for other people's misuse is relevant
Here's how other people's misuse of the tool can be relevant to the choice
of the tool: some tools are easier to use right than others. Probably the
easiest thing to use right is the system you designed and built yourself.
I've considered distributing code with an Autotools-based build system
before and determined quickly that I am not up to that challenge. (The
bigger part of the challenge isn't writing the original input files; it's
debugging when a user says his build doesn't work). But as far as I know,
my hand-rolled build system is used correctly by me.
>> checks the width of integers on i386 for projects not caring about that
and
>> fails to find installed libraries without telling how it was supposed
to
>> find them or how to make it find that library.
>
>no idea what this rant is about.
The second part sounds like my number 1 complaint as a user of
Autotools-based packages: 'configure' often can't find my libraries. I
know exactly where they are, and even what compiler and linker options are
needed to use them, but it often takes a half hour of tracing 'configure'
or generated make files to figure out how to force the build to understand
the same thing. And that's with lots of experience. The first five times
it was much more frustrating.
>> Configuring the build of an autotools program is harder than
nescensary;
>> if it used a config file, you could easily save it somewhere while
adding
>> comments on how and why you did *that* choice, and you could possibly
>> use a set of default configs which you'd just include.
>
>history shows this is a pita to maintain. every package has its own
build
>system and configuration file ...
It's my understanding that autotools _does_ provide that ability (as
stated, though I think "config file" may have been meant here as
"config.make"). The config file is a shell script that contains a
'configure' command with a pile of options on it, and as many comments as
you want, to tailor the build to your requirements.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
