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) 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 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...?
> 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. > > 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.
-- Trond Danielsen -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
