This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Tue, 2004-07-27 at 07:00, Dan Kegel wrote: > In http://lists.samba.org/archive/distcc/2004q1/002167.html, Dag Wieers wrote: > >>By the way, since there are so many combinations of processor, gcc version, > >>and glibc version, it would be hard to build all the RPMs for those > >>combinations. ... > > > > True. But there's no need to compile all combinations and RPM may help in > > building for different architectures too. ... > > > >>If you're supporting a stable of engineers working on the same > >>project, it's worth building the combinations you need once > >>(possibly as an RPM, if that's how your site likes things). > >> > >>But Fedora probably wouldn't want to include all the possible > >>RPMs my script can spit out. > >>This is a case where package managers have a bit of > >>a disadvantage compared to an engineer downloading the build script > >>from http://kegel.com/crosstool and just building the damn thing themselves. > > > > I respectfully disagree. I see what you mean, but even Source > > RPM packages are very handy to build for different targets with different > > options from a single source. So even when I wouldn't have the combination > > some engineer need, I guess if crafted good, a single SRPM would suffice. > > > > So when I find the time I'm going to look into your tool and see how I can > > take advantage of it as I've been always interested in providing this. > > OK, I'm finally adding RPM support to crosstool. I'm starting > with the spec file contributed by Charlie Brady, > http://kegel.com/crosstool/current/contrib/crosstool-mipsel.spec > and am parameterizing it; all.sh will fill in e.g. the > version numbers for the tools in use. > I'm probably going to stop short of generating .srpm's; generating > working .rpm's is enough for me for the moment (so the .spec > files I generate will be completely bogus except for the > %files section and whatever is needed to get that to work). > > (I still don't know how to > make a single .SRPM for multiple targets, though. It's darn complicated ;) >From my experience (I am the author of the RTEMS cross toolchain rpm-specs), if you really want to provide a single SRPM, you probably will have to resort to passing the target via rpm-defines (rpmbuild --define 'xtarget xxxx'). For RTEMS cross-toolchains (They are newlib based and not based on your crosstools package), I went a different way and am generating individual specs for each target, using auto*tool-magic and am using nosrc.rpms instead of src.rpms. > "What Does RPM Do To Make Multi-Platform Packaging Easier" at > http://www.rpm.org/max-rpm/ch-rpm-multi.html talks about > rpm's multi-platform features; they might help for handling multiple > build systems, but provide no help for multiple targets.) Exactly this outlines two-leaf Canadian Crosses (build != host). (We (www.rtems.org) build RTEMS cross-toolchains for Cygwin under linux using linux->Cygwin and linux->RTEMS cross toolchains and rpm). Ralf ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |