On 08/21/10 16:54, Dag-Erling Smrgrav wrote:
> Nathan Whitehorn<firstname.lastname@example.org> writes:
>> I'm the first to admit that many of the config tricks involved in this
>> port, and GENERIC64, are ugly hacks, largely because config(8) was not
>> designed with such things in mind.
> It's not just "config tricks and ugly hacks", it also violates the
> assumption that target names are unique.
This was discussed on arch several months ago. Breaking that assumption
seems much better, in the long term, than any of the alternatives in
order to accomodate mips[el|eb], arm[eb], powerpc, and any other
similar situations we may run into in the future. Sharing an
include/machine directory, which is a side effect, also means that
things like cc -m32 work out of the box.
>> To address the immediate problem, I think the best solution is to use
>> the -m option to config to reject kernel configs for different
> I'm not sure I understand what you mean (or rather, how it would help
> the tinderbox). What *would* help would be an easy way to determine,
> *before* trying to build it, whether a specific kernel config is
> appropriate for a specific target. Can you think of an easier way to do
> this than to scan the config for the "machine" line?
That's exactly what I proposed. You use config, before trying the build,
to look up the machine specification for the config file. I sent you a 5
line patch to tinderbox.pl that does this by private email. Other
alternatives would be having sys/$MACHINE/conf.$MACHINE_ARCH directories
or something, but that invites far more breakage.