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 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
