On 08/21/10 16:54, Dag-Erling Smørgrav wrote: > Nathan Whitehorn<nwhitehorn_at_freebsd.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[64][el|eb], arm[eb], powerpc[64], 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 >> architectures, >> > 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. -NathanReceived on Sat Aug 21 2010 - 20:01:57 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:06 UTC