This is the mail archive of the crossgcc@sourceware.org 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]

Re: crosstool-NG's dependency on version control systems


On Sun, Dec 19, 2010 at 9:02 AM, Enrico Weigelt <weigelt@metux.de> wrote:
> * Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote:
>> Anthony, All,
>>
>> On Saturday 18 December 2010 17:44:43 Anthony G. Basile wrote:
>> > Reading through scripts/functions, I found that crosstool-NG (may) need
>> > cvs, svn and git to download. ÂAre these the only version control
>> > systems that it depends on? ÂI'm 99% sure but I just wanted to make sure
>> > I hadn't missed anything.
>>
>> - cvs is used to retrieve devel versions of elf2flt and newlib.
>> - svn is used to get devel versions of eglibc.
>> - git is currently unused.
>
> We could get rid of cvs and svn by using git mirrors (I'm already doing
> that in the oss-qm project).

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

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.

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.

> In the next step we could even get rid of
> text-based patches by directly using git branches/tags ;-p

I see where you are coming from, but this isn't how crosstool-ng works.

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.

> cu
> --
> ----------------------------------------------------------------------
> ÂEnrico Weigelt, metux IT service -- http://www.metux.de/
>
> Âphone: Â+49 36207 519931 Âemail: weigelt@metux.de
> Âmobile: +49 151 27565287 Âicq: Â 210169427 Â Â Â Â skype: nekrad666
> ----------------------------------------------------------------------
> ÂEmbedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
> ----------------------------------------------------------------------
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
>

-Bryan

--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]