sdcc - Cross Compiler, Needs Packaging Standards?

[Trond Danielsen]

2007/2/23, Hans de Goede <j.w.r.degoede at hhs.nl>:
>
>
> Warren Togami wrote:
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=226795
> >
> > It appears that a few folks want sdcc, but do the packaging standards
> > for cross compilers and the concern about names being dropped into
> > /usr/bin should be solved first?
> >
>
> 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.

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.

> 2) About the cross compiling gcc guidelines I've been having both on and
>    off-list discussions on this topic with Ralf Corsepius, mostly we
>    agree on what I proposed in my initial mail about this from this
>    week:
> https://www.redhat.com/archives/fedora-extras-list/2007-February/msg00329.html
>
>    Besides my post we also have:
> http://fedoraproject.org/wiki/PackagingDrafts/CrossCompilers?highlight=%28Packaging%29
>    Which was created by Tibbs over a year ago in response to a package
>    review request for cross-compile stuff by Ralf. This is mostly
>    compatible with my proposal, but less complete. The only difference
>    is that both Ralf and I don't like the proposed prefixing of cross-
>    in front of the packages, if one installs arm-linux-gcc on a x86_64,
>    its obvious that its a cross compiler and the names will get long
>    enough with just prefixing the canonical target.
>
>    Other then from Ralf I have had 0 replies. Ralf had the same
>    experience when submitting 2 packages as a first try for review, that
>    was over a year ago and noone has responded, except for Tibbs setting
>    up the wiki page, which also has bitrotted since then.since Ralf and
>    I seem to be the only ones seriously enough interested in this to
>    actually invest  time, I suggest that we (Ralf and I) form a
>    cross-compile / embedded SIG and work out a set of guidelines for
>    cross stuff within this SIG, much like the Games SIG has some
>    additional Guidelines for games.
> >    Since Ralf and I agree for 99.9% on my proposal, this really is
>    almost done. The only thing which I want discussed in a wider
>    audience / need more input in is the SRPM issue, quoting from my
>    original mail:
> "The SRPMS for all these packages will most of the time contain the
>  exact same tarbals as the native binutils / gcc / libs
>
>    Possible solutions:
>    a) Live with the extra diskspace / bandwidth cost this induces upon
>       our mirrors
>    b) *** Warning dirty hack ***
>       Test for the existence of the tarbal in RPM_SOURCE_DIR in %prep
>       and if it isn't there bail with a message howto get the tarbal
>       from the srpms for the native packages. We can use the sources
>       file and the look-aside cache to make the test for the tarbal
>       succeed on the buildsys. Advantages: saves tons of diskspace.
>       Disadvantage: slight inconvienience for people trying to rebuild
>       the srpm's manually. Large inconvienience for people doing
>       automated rebuilds (aurora for example)
>
> I honestly don't know what todo here. I kinda like solution b),
> except for the pain it causes to aurora and possible others."
>
> So what do you think / any advice on the SRPM issue Warren?
>
> Regards,
>
> Hans
>
> --
> fedora-extras-list mailing list
> fedora-extras-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-extras-list
>

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.

-- 
Trond Danielsen