Re: PATCH [0/3]: Simplify the kernel build by removing perl.

[Rob Landley]

On Friday 16 January 2009 08:54:42 Valdis.Kletnieks@xxxxxx wrote:
> On Fri, 16 Jan 2009 00:11:09 CST, Rob Landley said:
> > P.S.  I still hope autoconf dies off and the world wakes up and moves
> > away from that.  And from makefiles for that matter.  But in the
> > meantime, I can work around it with enough effort.
>
> What do you propose autoconf and makefiles get replaced by?

At a first guess, meaningful standards and an acknowledgement that Linux is a 
platform in its own right?  Between the two of them, that's 90% of your 
problem right there.

Not a new issue, here's a link from 2002:
http://news.cnet.com/2100-1001-950180.html

And here's a multi-vendor effort at a standards group (the 86open project to 
definite a Unix binary standard for x86 processors) dissolving itself way back 
in 1999 with a declaration that the Linux binary format already was an open 
standard and other unixes should just use things like lxrun to support that: 
http://www.telly.org/86open/

Also, it would be nice if configure steps could stop entangling 1) users 
providing preferences (command line options like --prefix or most of the --
enable and --disable flags) for which things like kconfig might make more 
sense, 2) probe for installed packages like zlib and enabling optional support 
if found, 3) questions like "does my build environment provide strlcpy()".  
Turning that into a big hairball does not help keep things simple.

> % wc pidgin/configure*
>   34287  118303 1004074 pidgin/configure
>    2499    7684   81532 pidgin/configure.ac
>
> Which you rather code, 2.5K lines of autoconf or 35K lines of configure
> script?

I consider it a false dichotomy.  I prefer "neither", and have seen it done 
successfully many times.

I've never built pidgin from source, but I've got the output of the binutils 
build in a log file.  How many of these tests are actually necessary on any 
Linux system:

checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking for suffix of object files... o
checking whether gcc accepts -g... yes
checking for library containing strerror... none required
checking how to run the C preprocessor... gcc -E
checking whether build environment is sane... yes
checking whether gcc and cc understand -c and -o together... yes
checking for an ANSI C-conforming const... yes
checking for inline... inline

It just goes on and on and on like this.  Tests like "checking whether byte 
ordering is bigendian... no" means "Either I didn't know endian.h existed, or 
I don't trust it to be there".  How about the long stretches checking for the 
existence of header files specified by posix?  Or this gem:

checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk

(If you can use awk, when is it _not_ there?  Probable answer: there was some 
broken version on irix back in 1992 with zero remaining seats today, and they 
never went back to clean anything out of the makefile because "simplifying the 
build" and "autoconf" do not go together, and because you can't sanely 
regression test against build environments nobody has anymore.)

This argument is a can of worms, and the linux-kernel list probably isn't the 
best place for it.  However, "install mingw on windows instead of trying to 
get your thing to build under Visual Studio" is a decent support strategy.  
Tinycc and Intel's icc both implemented gcc extensions to build the kernel, 
and the kernel's been removing such extensions where c99 versions are 
available since then.  Things like uClibc implement standards and copy glibc 
extensions that are actually used.

In the era of open source, it's now a viable strategy to specify, document, 
and require a standardized build environment.  The way to make that build 
environment portable is to keep it simple and standardized, not to create a 
tower of #ifdefs testing the output of a huge environment probing shell 
script.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/