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

Re: sdcc - Cross Compiler, Needs Packaging Standards?

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

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

   Besides my post we also have:
   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?



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