Reminder: Use of target, target_alias, and target_{cpu,os,vendor}

[Phil Edwards <phil at jaj dot com>]

The contents of subject: line are something that we usually don't
need to care about, but that I'm going to start watching.  My spiffy
new box happens to have Athlon cpus instead of Intel.  So, inspired by
Jan Hubicka's x86 configury patch last December, and Alexandre Oliva's
use of an athlon-pc-linux-gnu target for testing, I submitted a patch
to the upstream config.* maintainers to allow athlon_mp as a cpu name.
(Which has been accepted, and imported from upstream, and now we can take
advantage of config.gcc knowing about the various Athlon instruction sets.)

Imagine how surprised I was when check-abi refused to run.

Why?  Because I foolishly pointed the default baseline file to $target_alias
instead of $target, and the _alias forms are exactly what the user types,
i.e., not canonicalized.  The canonical form is $target, and it's that
string that then gets broken into target_cpu and the rest.  (Automake then
adds a target_triplet=target assignment to the generated Makefile.in's.)

In my case, since config/abi/athlon_mp-pc-inux-gnu/baseline_symbols.txt
doesn't exist, abi_check threw a fit.


This is why, BTW, configure.target points the default baseline file at
$target instead of $target_alias.  We use target_alias all through the
configury (mostly in include/Makefile.am), but in a good way.  And the
checks against cpu and whatnot are done on the canonicalized form, so in
my case, target_cpu is still i686.

Things to remember while referring to configuration triplets.


Phil
(This is also why I wrote "tested on i686, sortof" in my check-abi patch.
It was fully tested on an athlon_mp, but that uses the i686 baseline.)

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002