crosstool-NG's dependency on version control systems

Enrico Weigelt
Sun Dec 19 19:35:00 GMT 2010

* Bryan Hundven <> wrote:

> You could, but some people like to work in the official repository if
> they are going to contribute change back to that software project.

That's not a big deal. Git can export patches or directly push
into other VCS'es.

For our case here, it wouldn't make much difference at all as patches
are currently maintained separately. So if somebody wants to contribute
back, he will have to grab the right patch file and send it to the
upstream maintainers nevertheless.

> In my honest and personal opinion (as crosstool-ng is not my project,
> it is Yann's), if you really want to download
> gcc/binutils/(e)glibc/etc... from a git mirror, why not make it
> optional. Or write your own wrapper script around crosstool-ng that
> downloads the source code and touches the .pkg-version.extracted and
> .pkg-version.patched files before running crosstool-ng.

That would add additional complexity that would have to be maintained
and doesn't really serve the purpose: my idea is to completely get rid
of patches and instead directly work within the VCS (and so use it's
sophisticated operations, eg. rebase, remote synchronization, etc).
It's a completely different workflow, a different way of thinking.

> At least provide a menu configuration that allows you to choose
> svn/cvs/bzr/etc... or git to download gcc, etc...
> But leave the original and official source repository as the default.

What's your goal in conserving the old tarball download or old VCS'es ?
The git repo will contain exactly the upstream trees, and additionally
crosstool-ng patched ones. In the end it's just a different medium
with same content, but it allows much more sophisticated operations
(removing the burden of maintaining text-based patchfiles, saving
bandwidth and storage, etc, etc).

> Looking at the heritage of crosstool-ng, specifically crosstool, Dan
> Kegel would not accept patches unless it was verified upstream to do
> the "right thing" or if it was a patch that fixes an issue in an older
> version of "pkg" that is already fixed upstream in a newer version of
> "pkg" but not back-ported to the older version of "pkg". But even the
> later has it's limitations, for instance if that fix for the newer
> version of "pkg" depends on features from the newer version.
> I agree with Yann and Arnaud that we should not blindly accept patches
> to packages built by crosstool-ng and to continue with the heritage of
> crosstool-ng to verify patches with the upstream maintainers before
> considering acceptance.

This is completely orthogonal to whether the changesets in ct-ng are
maintained as text-based patches or within an VCS. In both cases the
end-product is an tree generated by upstream + ct-ng patches. Whether
Yann adds/changes a patch in ct-ng from one release to another or
changes the trees in git does not really matter for the output.
Just the path is different (and wouldn't have to be reproduced
by ct-ng itself on each single build).

 Enrico Weigelt, metux IT service --

 phone:  +49 36207 519931  email:
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme

For unsubscribe information see

More information about the crossgcc mailing list