Is "host" the build or the target system?

[Magnus Ihse Bursie]

On 2012-05-25 00:46, Kelly O'Hair wrote:
> On May 24, 2012, at 2:13 PM, Fredrik Öhrström wrote:
>
>> Hey guys! You are falling into the old tar pit of "not invented here" mentality that Sun was rather (in)famous for.
> I politely disagree, and am a little insulted, being a long term Sun developer.

I think it's unfortunate to speak in terms of "infamous old Sun 
mentality". It's neither productive nor true; as you well know I'm by no 
means a long-term Sun developer.

> I'll be willing to bet that this autoconf change had quite a few 
> complaints when it was rolled out. 

My understanding is that it's the other way round -- the 
cross-compilation options have been there from the start, but have 
slowly been sanitized (from something even worse than the current 
state). Autoconf has always made things in it's own very special way, 
but many projects have chosen not to use, or have abandoned, autoconf 
for that reason.

>> You are running on i686-unknown-linux-gnu,
>> you want to build a cross compiler, then use:
>> --target=sparc-sun-solaris2_10 when configuring gcc
>>
>> Now you want to use your newly created cross compiler (sparc-sun-solaris2_10-gcc in your path)
>> to build a binary of application foo, for your sparc:
>> --host=sparc-sun-solaris2_10 when configuring foo
> I bet I could count on one hand the number of people that would actually want to build a cross compiler
> for the JDK, this is such a rare event.

I think you are still mixing up the two different cross-compilations 
that are involved when discussing autoconf. :-) Read again what Fredrik 
is writing: in the first paragraph, he is not talking about building the 
JDK, he's talking about building *gcc*. And I *still* think that's 
irrelevant to our current discussion. There might very well be weird 
options when you build gcc, after all, you have a more complex situation 
when cross-compiling a cross-compiler. So be it. But that's the gcc 
project. There's no reason why the terminology of the gcc project should 
govern our product.

> But seriously, you are making an argument that we should not try and modify the meaning or behavior
> of the autoconf options because it will only serve to confuse matters in the future and for existing autoconf users.
> So even though I think it's autoconf that has created the confusion, I see your point.
And once again I say that my solution will accept existing autoconf 
options, so existing autoconf users can still work as they are used to. 
And those un-accustomed to the autoconf way of naming things can use the 
tradition of naming the target "target". Everybody wins!

But I think the important issue is being clouded or lost here. If the 
tools we use are bad or confusing, it's our goal in the build-infra 
project to *shield* the users from that mess, not expose them to it. 
Autoconf is a tool that helps us implement our configure script. It's 
basically quite good at it (even though it has it's quirks), but it's 
still just a tool, not a doctrine.

> If we accept that we are adopting autoconf, which I think we did, then we probably shouldn't try and change it's
> basics and stick with just adding our special options.

Nah, nah! We already *had* changed configure "basics" in several cases, 
warping and twisting it to our needs. Some examples:

* You are supposed to create the build output directory yourself and run 
configure from there, instead of having configure create it for you as 
we do. My co-worker Jonas from the MySQL team (who is currently helping 
us with build-infra) thinks it's "weird and very un-autoconf behavior". 
:-) I think it's a great usability feature (introduced by Fredrik, btw).

* Since you normally run configure from the source root, the behaviour 
above combined results in that the typical way of configure projects is 
to store the build output (the *.o files) in the same directory as the 
source code (*.c). We don't want to do this for several reasons, so we 
don't. Jonas from MySQL also thinks this is breaking with a good 
tradition. :-)

* We don't let configure generate the Makefile. Most projects using 
autoconf don't even have a Makefile until you've run configure, so you 
can't run make by mistake before you've run configure. Of course using 
autoconf without using automake works well (that's what we do), but it's 
not the typical autoconf behavior.

* We're mis-using the --with and --enable options. According to the 
autoconf manual, --with should be used if your project "require, or can 
optionally use, other software packages that are already installed", and 
--enable is used to "choose which optional features to build and 
install. --enable-feature options should never make a feature behave 
differently or cause one feature to replace another. They should only 
cause parts of the program to be built rather than left out.". We're 
using them for stuff like --with-override-langtools or --disable-ccache. 
Which I think is fine. :-) But it's not as the authors of autoconf 
thought or designed the system.

Don't get me wrong here. I don't think we stop doing these things. I 
think they all are good solutions to our needs. But I think they point 
out an important design principle for build-infra, that we are using 
autoconf as a tool that we need to shape to our needs, not a iron-cast 
form that we need to adapt our needs to.

/Magnus