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

gcc-cross-dev details and future plans


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.

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.

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?

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.

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.

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. 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

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?


Reply to: