Is "host" the build or the target system?

[Kelly O'Hair]

On May 25, 2012, at 5:02 AM, Magnus Ihse Bursie wrote:

> 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.

No I understood it was building a cross compiler, a "gcc", and I still say this is a rare event, rare to
want to even build a cross compiler, even rarer to build one specifically for JDK building.
I agree with you that this compiler building terminology just confuses the more common situations.

> 
>> 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.

I agree it is still a tool, not a doctrine. But we need to be careful that if we change it too much, such that
it is no longer what it was, we might be buying ourselves a large maintenance burden as that
tool goes though upgrades we want to adopt.

> 
>> 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.
> 

I wasn't involved in those specific choices, and can't comment on them in detail, but you make a point.
We have already adapted it.

> 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.

I agree with you, we need to shape it to our needs, but it's how far we go that is the question.

I'm feeling a little out of my element here with autoconf. My history is with the old makefiles, and all the
special case madness of building a JDK on lots of OS's and arch's with old and custom makefiles.

I think you and Fredrik and maybe Erik need to iron this out.

-kto

> 
> /Magnus
>