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

Re: sdcc - Cross Compiler, Needs Packaging Standards?



On Sat, 2007-02-24 at 15:18 +0100, Trond Danielsen wrote:
> 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)
.. 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



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