On Fri, 10 Apr 2015, Martin Lucina wrote: > On Thursday, 09.04.2015 at 16:20, Joseph Myers wrote: > > > Why do you not recommend using the vendor component for anything > > > significant? To me it seems the logical place to say "this is a rumprun > > > toolchain", plus the result is easier to parse than putting "rumprun" AND > > > "platform" AND "userspace" all in the last component. > > > > The vendor component is typically a company name - used either in cases > > where only one name is normally used (*-sun-solaris*, *-hp-hpux*, > > *-ibm-aix*, etc.), or, for free software systems, for branding purposes if > > at all (*-<company>-linux-gnu*). Presumably multiple distributors might > > each distribute rumprun tools, branded for that distributor, so > > <cpu>-<company>-linux-gnurumprunxen or <cpu>-<company>-netbsd-rumprunxen > > for example. > > You say "typically a company name", presumably that is custom but not a > requirement?
Well, config.sub says MANUFACTURER. Presumably multiple MANUFACTURERs could produce compatible rumprun toolchains (and so put their own identifiers in that slot). > "2" and "3" have the advantage of working with existing config.sub scripts > out of the box. "1" would require submitting a patch to autoconf and, until > upstream packages regenerate their build scripts using the new autoconf, > that we run autoreconf before building software in order to get the new > config.sub. This would also mean instructing end users/porters to do the > same. GNU/Linux distributors are very used to needing such regeneration whenever doing new architecture ports (or possibly patching config.sub to exec a system copy so it can be patched once and not need repatching for each new architecture). I don't think whether a config.sub patch is needed should be a relevant consideration. -- Joseph S. Myers jos...@codesourcery.com
