Re: gcc-cross-dev details and future plans
+++ Dima Kogan [2014-12-17 18:24 -0800]:
> Hi.
>
> I'm merging the master and archindep branches of the cross-gcc tree
> (ssh://git.debian.org/git/crosstoolchain/cross-gcc.git). Some questions
> are coming up about the correct way to handle some details, hence this
> email. Please speak up if you want something done differently. In no
> particular order, things I've done/am going to do:
>
> Currently the cross-gcc tree and its products are marked as being
> maintained by Wookey alone, so any upload by me or anybody else is
> technically an NMU. I'm changing this to be Maintained by the cross-gcc
> team, and calling out Wookey and myself as Uploaders.
Good plan.
> In the master branch, I was using the debian/target file to specify the
> target arch, in addition to either the env var or --target-arch. Those
> were all broken at some point in time, so I'm using two of these. I'm
> now doing this in archindep too. This is in effect a workaround #773065,
> but is useful in any case.
I'd prefer to do this 'right' and use --target-arch where possible as
that should be where we all end up eventually. The existing code
checks the current dpkg _has_ --target-arch and then uses it, or falls
back to DEB_TARGET_ARCH. But then that broke in 4.9.2-7 with changes
due to #768167
So long as cross-gcc is supplying a lof of gcc patchage it is very
specific to a particular version of gcc, and not really a general
purpose tool for building any version of gcc-4.9 (which it was when it
started). Given that, we should know which target-selection runes are
currently going to work.
So I'd vote for applying the 773065 patch and just using
--target-arch, and hope that we can drop that in a while, but I guess
there is no real harm is using debian/target as well, except for a
smidge of extra complexity in cross-gcc.
> The control file in the cross-gcc-dev template has Build-Depends:
> gcc-4.9-source(>= 4.9.2-4). However, the patches have not been checked
> to be applicable to (>= 4.9.2-4). We either need to keep track of this
> more rigidly, or simply set the Build-Depends to gcc-4.9-source(=
> 4.9.whatever). I intend to do one of those things. Anybody has problems
> with the latter, maximally-restrictive option?
Yes this is from when it diverged from master. We have switched master
to specify an exact gcc-source version, for the patching reasons
covered above, so archindep should follow. If we get gcc and
cross-gcc more aligned again so that the patches disapear then this
can become less restrictive. I would be better if cross-gcc was not
specific to a particular gcc-4.9, but that can only happen if it
doesn't have a big patch pile.
> Currently, since cross-gcc-dev is a package that produces a
> debianization, there are two sets of debian/ directories:
>
> - the one to build cross-gcc-dev
> - the one cross-gcc-dev uses to generate source. This is in templates/
>
> Should the debian/changelog and debian/copyright files of those two
> match? I think the answer is "yes", and appropriate machinery should be
> put into place to guarantee that.
Makes sense. If they are always the same then they don't need to come
from the template dir, and we just copy the originals, so that's dead easy.
> I want to get rid of cross-gcc-buildall. Its existence implies that the
> sources must be built with this special-purpose script, which as far as
> I know is not true. The sources can be built with sbuild or
> dpkg-buildpackage or any of the other usual things. At the very least, I
> don't want to ship this in the cross-gcc-dev package.
Hmm, it's a handy script which I've been using to do the builds,
because it iterates over the architectures and runs sbuild for
each. And it matches the paths used by gensource. So it is a
convenient thing. But I guess you are right that it's not actually
necessary in the binary package. I suppose it is largely replaced by
your auto_build_all.sh script, in which case dropping it from the
binary package makes sense.
> And now, a larger question. What is the PURPOSE of the cross-gcc-dev
> package? Helmut needed something he could apt-get install that contained
> the patches, and he's only using those; not the scripts.
The patches _and_ the rules.
So the point of this package is that because the control file for each
cross-gcc-4.9-$arch differs (and we are currently building one
cross-toolchain from a source package, not all of them) there has to
be a source package uploaded for each cross-toolchain. Maintaining
those separately is a bad plan (skew, faff) so generating them all
from canonical source is good. We were doing that with just the
cross-gcc git repo anduploading the source packages. having
cross-gcc/cross-gcc-dev move this machinery into a package in the
archive, instead of a git repo on alioth.
As helmut pointed out not having that was arguably a software-freedom
issue - the 'preferred form of modification' wasn't actually in the
archive. So cross-gcc fixes that, and using the binaries/rules/patches
that are shipped in cross-gcc-dev to generate the source packages is
good.
Then the other aspect was to have _one_ rules file so that the
individual cross-gcc-4.9-$arch packages used the generic rules file
shipped in cross-gcc-dev.
All this makes it easy to build architectures that are not
uploaded/built in the archive (e.g. x32)
It does mean that the different cross-gcc-4.9-$arch packages now
_can't_ diverage far from each other (because they use centralised
rules and patches), but the current MA-builds mean we have lockstep
for other reasons anyway, so I don't think this is bad.
> I want a simple
> way to build the toolchains, and this extra layer of indirection is not
> welcome for that. Is there a specific consumer for whom building the
> toolchains from the installed cross-gcc-dev package is better/easier
> than doing so from a checked-out tree? We can generate a package
> containing the patches for Helmut's use case, but still keep the build
> in-tree.
I agree the extra indirection is a bit annoying, but having
generalised rules rather than 6 identical copies in the generated
sources, and the same for patches does make a lot of sense. And I
think the 'preferred form of modification' argument is important too.
Why is it actually a problem for you?
The only thing I can see that might be an _actual_ problem is skew
between the cross-gcc-dev version and the cross-gcc-4.9-$arch versions
uploaded.
So I think you have missed the point about what cross-gcc-dev is
actually for, but maybe I am just missing your point?
What do you mean by 'keep the build in-tree'? Do you mean keep the rules
and patches copied into each cross-gcc-4.9-$arch source package, but
_also_ have them in a cross-gcc-dev for other usage? I guess that
could work too.
> I looked at what it would take to make this work both ways: by
> building/install cross-gcc-dev or directly from the source tree. This is
> mostly simple, except as currently-defined, the cross-gcc packages
> Depend:cross-gcc-dev to pull in the rules.generic file. I think it's
> important that if we do allow both ways of building toolchains that they
> produce equivalent output, and this dependency makes this impossible. I
> propose to either go back from using cross-gcc-dev to build the
> toolchains, or to include rules.generic in the cross-gcc Packages,
> instead of as an indirect dependency. Any preferences here?
I don't care enormously. I only changed it because helmut asked. But
now I've done that, I do see that having one copy rather than 6 of the
machinery makes sense, as does having that in the archive, rather than
just a gitrepo, and is probably worth the extra bit of packaging
complexity.
But I don't think I've understood why you prefer the way master works
over the way archindep works.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
Reply to: