sdcc - Cross Compiler, Needs Packaging Standards?

[Trond Danielsen]

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