Re: [PATCH 4 of 7] cc/gcc: Add support for getting a gcc snapshot

[Bryan Hundven <bryanhundven at gmail dot com>]

On Tue, Dec 7, 2010 at 10:42 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Tue, Dec 7, 2010 at 1:29 PM, Bryan Hundven <bryanhundven@gmail.com> wrote:
>> On Tue, Dec 7, 2010 at 7:19 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>> Hi,
>>>
>>> I had the same in my tree! You may want to have a look, in particular
>>> for the download section, which require some other change in the
>>> downloader utility cruft.
>>>
>>> Â- Arnaud
>>
>> Interesting. Thanks Arnaud!
>>
>> Not saying that I don't like your patch, it is just a different way of
>> doing things.
>> The way that I had incorporated snapshots has no changes to gcc.sh.
>> The thing that your patch is missing (maybe it is in a separate patch)
>> is the "real gcc version" (I called it CT_CC_REAL_VERSION), which is
>> needed during the finalize step in scripts/build/internals.sh.
>>
>> Even better then snapshot support, would be the ability to
>> checkout/export gcc from svn from a specific branch/revision, much
>> like eglibc.
> this can be trivially done with git. I still have patches, but I'm no
> longer using ct-ng, so I don't really care about them now. This is a
> reason why I do not want people to only contribute patches to ct-ng.

I think we are thinking the same thing here - about not liking patches
in the ct-ng build.
I feel that these patches should be temporary fixes until upstream has
fixed the problem we are experiencing.

If you're not using ct-ng anymore, what are you using? Just curious.
And why do you keep commenting on commits to ct-ng if you "don't really care"?

>> Binutils is a bit more different. They make a versioned snapshot
>> (binutils-2.21.51.tar.bz2), a daily snapshot (binutils.tar.gz), and a
>> weekly snapshot (binutils.weekly.tar.bz2).
>> But they all currently extract to 'binutils-2.21.51'. Because the name
>> of the archive is different then where the archive is extracted, it is
>> tempting for me to modify CT_Extract() to support these kind of
>> snapshot archives by basically running:
>>
> binutils has a git tree too.

Officially, binutils is still hosted on cvs:
http://sourceware.org/binutils/

But yes, it is also available via git:
http://sourceware.org/git/?p=binutils.git;a=summary

>> So that all binutils snapshots live in ${CT_SRC_DIR}/binutils-snapshots
>>
>> It's good to know that we have some things in common ;)
>>
> well, that was fun hacking around it, but ct-ng has too many
> limitation and architectural defect which cannot be easily
> worked-around. Maybe I should put my git repo online a day or another.

I'm interested to know the architectural limitations/defects that
crosstool-ng has.
Maybe we could move crosstool-ng to a "trac" site (or something
similar) where we can keep track of bugs, and have the ability to set
"milestones".

AFAIKT, crosstool-ng is a very flexible system. I also have some
patches to ct-ng that have not been posted here, because I know they
won't be accepted.
Just because a patch isn't accepted by Yann, doesn't mean that you
can't use them. Just don't complain to Yann/crossgcc when they don't
work as advertised.

When I post patches here, I don't expect them to be merged into the
main crosstool-ng repo.
I put them here because they were useful to me, and might be useful to
someone else as well.
If/when Yann merges them, it is because he also found the patch(es)
useful as well.
I try not to feel offended if they don't get merged, because they are
still in my mercurial mq. ;)

> Â- Arnaud

-Bryan

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