[Fedora-packaging] Re: Cross-compiling guidelines

[Kevin Kofler]

Rex Dieter <rdieter <at> math.unl.edu> writes:
> http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers

My opinion about these:

> Naming
It's hard to tell the right thing to do here. Some things to consider:
* The current cross-compilation packages for the AVR don't have the "cross-" 
prefix, if you want to mandate it, those packages will have to be renamed.
* While I can see the use of the "cross-" prefix for packages like "gcc" 
or "binutils" which already have a native version (though 
IMHO "i386-rtems4.7-gcc" is enough to specify that, and it would also have the 
advantage of fitting with the names of the executables as installed by upstream 
GCC), packages like "tigcc", "sdcc" or "z88dk" are implicitly cross-compilation 
packages and definitely don't need a "cross-" prefix. In fact, z88dk and sdcc 
are already in Fedora with those names, and I don't think adding "cross-" in 
front would make any sense for these.
So all in all I think mandating the "cross-" prefix is not that great an idea, 
but I'm open to discussion on this point. I'd suggest a guideline like:
"If the cross-compiler does not have a native equivalent with the same name, 
and if the compiler either supports only one target or includes support for all 
targets in the same package, using the upstream name for the package is 
sufficient. An example is 'sdcc'. Otherwise, prefix the package name with the 
target name, e.g. 'avr-gcc' or 'i386-rtems4.7-gcc'."

> File Naming
I don't think dictating the exact names of files installed into the bindir is a 
good idea. As in the above case with the package names, I don't think prefixing 
names which are already unique upstream is a good idea, consider names 
like "tigcc" or "tprbuilder", they don't conflict with any other package's 
files. If the names would conflict, e.g. with native tools, again prefixing 
with the target name is the right thing to do, and in fact what the GNU 
toolchain already does.

> File Locations
As Ralf explained, /usr/targetname is what the GNU toolchain uses by default, 
so if you want anything else, you'll be up for patching the toolchain. A lot of 
patching. I know what I'm talking about here, TIGCC patches GCC so it can work 
out of any directory (it doesn't currently support split installations, i.e. 
the "/usr/{bin,lib,...}/ARCH-ENV" suggestion would need patches to TIGCC too) 
and that needs a lot of adjustments (patching all the hardcoded paths out of 
GCC, there's a lot of those, then using a "tigcc" wrapper which among other 
things passes the correct -B option to GCC to set the real location at 
runtime). Just changing the hardcoded paths to something different might be 
easier (than full relocatability as done in TIGCC) though. As for split 
installations, I don't know, the GNU toolchain does use stuff like 
prefix/lib/gcc/target/version/ and prefix/libexec/gcc/target/version, but I 
don't know how hard it is to get it to use _only_ such directories.

I think going with a prefix of /usr/targetname is probably easiest, it's the 
recommended/default way for the GNU toolchain and it's most likely to work with 
other toolchains too. (It definitely works for TIGCC.) If other toolchains need 
different directory setups, these can always be looked at on a case-by-case 
basis (and allowed as alternatives).

Another open question is: what does "targetname" have to include, in particular 
for non-GNU toolchains? Does it have to be a full target triplet, 
e.g. "m68k-ti-tigcc"? (But "avr-" already isn't...) Otherwise, what parts are 
required? Is the CPU required (e.g. "m68k-tigcc")? Or would installing 
to "/usr/tigcc" be OK? My personal opinion is that any target name which 
uniquely identifies the target is OK, if that's just "avr" or "tigcc", that's 
OK, if it needs more components (e.g. "i386-rtems4.7" 
vs. "someothercpu-rtems4.7" or "i386-someotheros"), then these are required.

        Kevin Kofler