[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: sdcc - Cross Compiler, Needs Packaging Standards?



2007/2/24, Hans de Goede <j w r degoede hhs nl>:
Hi All,

Trond Danielsen wrote:
> 2007/2/23, Hans de Goede <j w r degoede hhs nl>:
>>
>>
>> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]