On Sat, 2007-02-24 at 15:18 +0100, Trond Danielsen wrote: > 2007/2/24, Hans de Goede <j.w.r.degoede@xxxxxx>: > > Hi All, > > > > Trond Danielsen wrote: > > > 2007/2/23, Hans de Goede <j.w.r.degoede@xxxxxx>: > > >> > > >> > > >> 1) The cross compile stuff being discussed so far was about a cross > > >> compiling binutils + gcc + libs, sdcc is a whole different compiler, > > >> which comes with its own libc (I think) etc. packaging sdcc sure > > >> would be interesting, and could/should try to follow the guidelines > > >> being developed for cross-gcc where possible > > >> > > > > > > Even though sdcc comes with its own libc, and are different from gcc > > > in many ways, I do think it makes sense to follow the same guidelines > > > as other cross compilers. This makes everything more consitent. > > > > > > > I'm not sure I've just taken a look at the spec-file for sdcc from your > > review request: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795 > > > > And I like what I see, I think that there are 3 distinct issues we need > > to look at when packaging cross-compilers / cross-development tools: > > 1) What does upstream's makefile / configure do by default, deviating > > from this will cause troubles, cause many makefiles for projects > > intended te be build with this tools will break if we put things in > > other places. This is especially important when the build-chain > > consists of multiple parts as it does with binutils/gcc/xxxlibcxxx > > because if we decide todo things different there the spec files > > will turn into huge patch fests to get things further down the chain > > to build (and we will be inflicting similar pain on people trying to > > build existing stuff with our tools. > > > > 2) Try to be as FHS compatible as possible, except where this breaks 1 > > > > 3) Files most not conflict, so sdcc installing a /usr/bin/cc is a BAD > > idea (_fictional_ example). In the case were upstream doesn't do this > > themselves all files under /usr/bin must be prefixed with a common > > prefix. Likewise header files for cross development must not go under > > /usr/include, but in their own private dir. The same for libs. > > > > This leads to the conclusion that partially this will be a case by case > > job. For cross-compiling gcc(chain) rpms we can make guidelines, but I > > do not believe that we should force packages for other cross-compilers > > to follow these guidelines. On the contrary, I believe we should stay as > > close to upstream as possible, to minimize the element of surprise for > > end users. > > > > This is why I plea for a cross-compiler SIG, so far I know of the > > following people being interested: > > > > Hans de Goede (avr-gcc, arm-linux-gp2x-gcc) > > Kevin Kofler (tigcc) > > Ralf Corsepius (rtems) .. freebsd, cygwin, mingw ... > > Trond Danielsen (sdcc, avr-gcc, avr32-gcc, Analog Devices Blackfin) > > > > So assuming all named people are reading this, who's in? I'am in myself > > ofcourse and (see below) I believe Trond is in too. > > Confirmed. Count me in. > > > > > Then within this SIG we can try to create general cross compiling > > guidelines and where this makes sense because there is a whole family > > with a common pattern, per compiler-family guidelines. The document > > which I posted earlier: > > https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00329.html > > > > Is in me eyes a reasonable start for guidelines for the gcc-family of > > cross compilers. > > > > I think this is a very good starting point for a complete set of guide > lines. What remains is to create a wiki page, so that we can start > > > > The spec file for sdcc is almost complete, but I wanted to clarify > > > some of the questions I had regarding "best practice" with regards to > > > cross compilers. > > > > > > > As said I've taken a quick peek and I like it, what questions do you have? > > > > The main issue is the install path. avr-gcc installs everything into > $prefix/avr, which I think is a good solution. Somebody commented in > bugzilla This person was me ;) > that some of the names of the binaries from sdcc where to > generic, and I therefore moved the binaries to /usr/libexec/sdcc, and > created symlinks to /usr/bin. But I wonder if this is a good > solution...? Do you see any problem with it? I don't. To the contrary, you automatically get $bindir/<target>-<tools> as surplus, which is what the GNU toolchain applies and which is what modern autotools automatically support for cross-toolchains. > > > I would very much like to contribute to make this happend. I have both > > > a personal and professional interest in seeing as many tools for > > > embedded system development available in the Fedora repositories. > > > There are a number of tools that are missing, that would make Fedora a > > > more attractive target for engineers. A quick summary: > > > > > > - Tools for Atmels AVR and AVR32 processors. Both are supported by > > > free software tools. > > > - Tools for Analog Devices Blackfin. This DSP runs uclinux, and > > > compilers and other related tools are available. Toolchains for both targets also are available for RTEMS (avr-rtems*, bfin-rtems). > > > Once the guidelines are completed, I will get down to packing up as > > > many of these as possible. > > > > > > > Welcome aboard, notice that I've got a couple of last-year CS students > > working on packaging avr-gcc, so please contact me before things get > > done twice. Do me a favor, don't name cross tools "cpu", use a more specific name, such as avr-elf. "avr" is too unspecific to specify a particular toolchain, which, gnerally speaking, will always consists of more than just a "target" compiler. Ralf -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
