On Thu, 19 May 2016, Andreas Färber wrote:
Am 19.05.2016 um 13:12 schrieb Richard Biener:
On Sat, 14 May 2016, Andreas Färber wrote:
Hello,
Newlib [1] is a C standard library (i.e., alternative to glibc). [...] newlib serves as source package that further cross-*-newlib-devel.spec files can be generated in and _link'ed (similar to dtb-source package).
The gcc5 and gcc6 packages [7, 8] are already prepared for newlib.
The spec files used for testing specific cross-compilers have been dropped from newlib for now, as there is a two-step dependency between gccX and newlib, avoiding unresolvable build requirements in staging.
My suggestion is to merge this newlib stub package first. We can then branch newlib to devel:gcc, prepare gcc5 and/or gcc6 cross packages there and then submit gccX and newlib packages alongside through one staging project.
Alternatively we could first submit cross-*-gccX-bootstrap packages that don't depend on cross-*-newlib-devel packages yet, but they would be of little use on their own and should rather not get published (similar to systemd-mini package).
An oSC16 lightning talk [9] is planned with an update on this topic.
First of all thanks for continuing to work on this.
I have an issue with putting additional crosses into devel:gcc via the gcc5 or gcc6 source packages. Factory submissions require that all .spec files linking to the main package build which is quite a burden already with some of the "stupid" crosses we have. Adding in newlib crosses both increases build time and introduces new failure paths I would have to deal with.
This is probably a more general issue of multiple .spec files refering to the same source. I don't like the idea of splitting the source itself too much but eventually I will start doing this if things become too uncomfortable. That is, have a cross-gcc-source "stub" package aggregating all the cross spec files.
I don't mind you splitting your package, but FTR let me say that in the ~year that I've been building these cross packages I've never had a build failure that was not due to the tarball file name changing (and thus resolved by re-running my branched pre_checkin.sh - an issue we wouldn't have in devel:gcc) or a general build breakage of gcc5. I.e., zero failures due to newlib so far.
It's definitely not something I'll do immediately but only in case it becomes a problem for me when maintaining GCC.
Of course that's not a guarantee for the future. I agree this shouldn't hold up native compiler updates unnecessarily. On the other hand though any major gcc updates (gcc5, gcc6) go through long-term staging projects that would probably allow fixing any cross-compilation issues alongside. And if there's a breakage you could still comment out the broken targets in change_spec until someone fixes them. More specifically if we add cross-compilers to gcc5 today then gcc6 doesn't have them unless someone makes an SR to gcc6, which should require to have successfully built it first.
My main concern is that I would like to base our cross-compilers on a current and maintained gccX package, whether directly or indirectly. We already have separately packaged cross-compilers bit-rotting in CrossToolchain:sh4 and CrossToolchain:mingw:test and really don't need the same thing in devel:gcc. So if a branched cross-gcc5-source package breaks due to a gcc5 package update, aren't the effects the same as if we do it from gcc5 like today? Or would you want to keep cross-gcc-source completely separate (no _link) from gcc5/gcc6? Who would update it in that case and when?
I would make it a branch in devel:gcc but _not_ a branch/link in Factory (thus have another devel project that is not a branch of the factor package - gdb is/used to be another). The advantage is that sources stay in sync but factory sumbission of the core 'gcc' does not depend on submission of the cross packages.
Also for clarity, IMO non-upstream targets such as pru would need to stay in a separate project, to not break updating - similar to how our kernel packages don't contain random downstream patchsets.
Of course.
Richard.
--
Richard Biener