OT: cross compilation and autoconf [was: Re: runit not ready for cross-compilation]

[Charles Duffy <cduffy@spamcop.net>]

My apologies for dragging this thread on further. I've changed the 
subject so as to not interfere with more topical discussion.

Alejandro Mery wrote:
> what?? noone needs something like autoconf, just using simple sh scripts 
> and a simple Makefile (instead of .c helpers) is _enough_ to make 
> software cross compilable. and of course you wont run make test when 
> cross compiling, and there is no need to do that.

The software in question here may not need autoconf -- but there are 
cases where its more esoteric functionalities do indeed come in handy. 
I'm not arguing that autoconf makes sense here -- I'm just disputing 
that "no one needs something like autoconf".

In a former life I spent 2-3 years porting and packaging 3rd-party 
(mostly Free) software to be cross compiled to the 5 or 6 target 
architectures and 2 host platforms my employer supported, and in that 
time I ran across a *lot* of different compile-time tests. The strong 
majority of them could be resolved by attempting target compile and link 
steps (to validate headers and library contents) without actually 
needing to run anything on the target, but there were a few more obscure 
tests which did inded care about things that weren't really available 
without access to the target. (For instance: Are you on one of the buggy 
platforms where ferror() returns -1 instead of 0 on a file handle which 
does not in fact have its error flag set? How can you tell without 
actually trying?) [1]

Additionally, it's better to have something that's *consistent* and 
written to make cross compilation reasonably straightforward than for 
every package to have its own custom configure/build system (in which 
case maybe 10% of them have had ample thought put into allowing cross 
compilation, and fewer than that have actually had such functionality 
actually *tested* by the maintainers). To be sure, autoconf is a beast 
-- but it's a beast which has picked up much of its size in satisfying 
esoteric requirements. Every once in a while, someone *needs* those 
capabilities, and having them around is darned handy.


[1] - Okay, this isn't a great example -- one can just treat negative 
return values from ferror() the same way as one treats zero values, and 
it becomes moot. There are similar cases, however, where a method may be 
defined the same way in the headers of two platforms but have material 
behavioral differences between them such that a runtime test is 
necessary. No, I don't remember any -- this was 5 or 6 years ago.