ObjC tree inlining

ObjC tree inlining

[Neil Booth]

Alexandre,

When you did your inlining hooks, you added this to c-lang.c in
c_post_options():

  /* Use tree inlining if possible.  Function instrumentation is only
     done in the RTL level, so we disable tree inlining.  */
  if (! flag_instrument_function_entry_exit)
    {
      if (!flag_no_inline)
	{
	  flag_inline_trees = 1;
	  flag_no_inline = 1;
	}
      if (flag_inline_functions)
	{
	  flag_inline_trees = 2;
	  flag_inline_functions = 0;
	}
    }

However, nothing equivalent exists for ObjC (or C++ for that matter).
Should ObjC and C++ have this?

If so, let me know and I'll fix it in my next patch (I'm trying to
share more code between the 3 C family langhooks, and want the ObjC
post_options function to be the same as the C one).

Neil.

Re: ObjC tree inlining

[Alexandre Oliva]

On Nov 18, 2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:

> However, nothing equivalent exists for ObjC (or C++ for that matter).
> Should ObjC and C++ have this?

I copied this from C++.  IIRC, c-lang.c applies to objc too, so it's
already got it.  If not, feel free to correct my mistake.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: ObjC tree inlining

[Neil Booth]

Alexandre Oliva wrote:-

> On Nov 18, 2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:
> 
> > However, nothing equivalent exists for ObjC (or C++ for that matter).
> > Should ObjC and C++ have this?
> 
> I copied this from C++.  IIRC, c-lang.c applies to objc too, so it's
> already got it.  If not, feel free to correct my mistake.

c-lang.c is C only.  I think it would be good to create a C directory
for the C front end to dispel confusion like this.  It might also help
towards making C just another front end, rather than the somewhat
special status it currently has.  What do you think Joseph?

As for C++, like you said, I found some of the code in cp/decl.c.
However, it is not conditional on flag_instrument_function_entry_exit
like it is in c-lang.c.  -finstrument-functions is listed as language
independent.  Does this mean that the whole block of code should be in
process_options() in toplev.c where it is language independent?  If
not, why does this conditionality apply to C and ObjC only?

Neil.

Re: ObjC tree inlining

[Alexandre Oliva]

On Nov 18, 2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:

> Alexandre Oliva wrote:-
>> On Nov 18, 2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:
>> 
>> > However, nothing equivalent exists for ObjC (or C++ for that matter).
>> > Should ObjC and C++ have this?
>> 
>> I copied this from C++.  IIRC, c-lang.c applies to objc too, so it's
>> already got it.  If not, feel free to correct my mistake.

> c-lang.c is C only.

Oops.

> I think it would be good to create a C directory
> for the C front end to dispel confusion like this.  It might also help
> towards making C just another front end, rather than the somewhat
> special status it currently has.  What do you think Joseph?

Yup, I've entertained this idea for a while, but never got to
implement it.  Ditto for moving libgcc out of gcc into a regular
target library and moving the implementation of bootstrap to the top
level.

> As for C++, like you said, I found some of the code in cp/decl.c.
> However, it is not conditional on flag_instrument_function_entry_exit
> like it is in c-lang.c.

Yup.  I made it conditional in C because doing tree inlining would
mean we wouldn't be instrumenting inlined functions, because we only
instrument them as trees, only as RTL.  The same test should probably
be done in C++, or we should instrument functions as trees.  The
latter is definitely preferable, since we're phasing out RTL inlining.

> -finstrument-functions is listed as language
> independent.  Does this mean that the whole block of code should be in
> process_options() in toplev.c where it is language independent?

Nope.  The code inside the if block is what turns flags that would
have originally enabled rtl inlining into flags that enable tree
inlining.  We only want to do this on front-ends that support tree
inlining.  It could be moved to toplev.c if we introduced a language
hook that indicated the language supports tree inlining.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: ObjC tree inlining

[Neil Booth]

Alexandre Oliva wrote:-

> Yup.  I made it conditional in C because doing tree inlining would
> mean we wouldn't be instrumenting inlined functions, because we only
> instrument them as trees, only as RTL.  The same test should probably
> be done in C++, or we should instrument functions as trees.  The
> latter is definitely preferable, since we're phasing out RTL inlining.

OK.  For the moment, I'll move it to c-common.c unless I hear an
objection.

Neil.

Re: ObjC tree inlining

[Jeff Sturm]

On 18 Nov 2001, Alexandre Oliva wrote:
> Yup, I've entertained this idea for a while, but never got to
> implement it.  Ditto for moving libgcc out of gcc into a regular
> target library and moving the implementation of bootstrap to the top
> level.

Making libgcc a regular target directory could solve some configure
nastiness in which we choose the link rules for shared libgcc (e.g.
t-slibgcc-sld) before a "./xgcc -print-prog-name=ld" test is possible.

Jeff

Moving C to its own directory (was Re: ObjC tree inlining)

[Phil Edwards]

On Sun, Nov 18, 2001 at 04:59:53PM +0000, Neil Booth wrote:
> c-lang.c is C only.  I think it would be good to create a C directory
> for the C front end to dispel confusion like this.  It might also help
> towards making C just another front end, rather than the somewhat
> special status it currently has.  What do you think Joseph?

The usual objection to this is that it makes CVS history browsing more
difficult,e.g., the problems discussed in

    http://www.cvshome.org/docs/manual/cvs_7.html#SEC66

No matter which of the two or three methods of moving files we use, at
least one CVS operation will be much harder.

I raise this objection only to get it out of the way; personally I feel
we should just bite the bullet and move the files.  But I won't be nearly
as affected by the change as others.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On Mon, 19 Nov 2001, Phil Edwards wrote:

> The usual objection to this is that it makes CVS history browsing more
> difficult,e.g., the problems discussed in
> 
>     http://www.cvshome.org/docs/manual/cvs_7.html#SEC66
> 
> No matter which of the two or three methods of moving files we use, at
> least one CVS operation will be much harder.

It's established that we only ever use cvs add / cvs remove, and don't do
anything directly in the repository except for bulk imports of directories
previously maintained in CVS elsewhere (e.g. libjava).

What is the exact proposal?  That is, what goes in what directory, and 
does C become a language that should be named in --enable-languages (and 
is included in lang_requires for the other language subdirectories?)?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Neil Booth]

Joseph S. Myers wrote:-

> It's established that we only ever use cvs add / cvs remove, and don't do
> anything directly in the repository except for bulk imports of directories
> previously maintained in CVS elsewhere (e.g. libjava).
> 
> What is the exact proposal?  That is, what goes in what directory, and 
> does C become a language that should be named in --enable-languages (and 
> is included in lang_requires for the other language subdirectories?)?

I would propose that we move all C-specific (only c-lang.c I believe),
and C-or-ObjC files to a c/ directory.  I'm thinking of things like
c-decl.c, c-lang.c, c-tree.h, c-parse.in and c-typeck.c.  In the
process they should probably be renamed to remove the "c-" prefix,
with the exception of c-lang.c since that really is C-specific (and
the only such file I believe).

Things common to C++ as well as C/ObjC, like c-lex.c, c-format.c and
c-common.c are debatable, but IMO should go there too.  For clarity, I
would rename those so they have a "common" suffix, e.g. lex-common.c,
fmt-common.c, and common.c (avoiding the 8-3 and 14 issue).  I see
plenty of scope for code that is currently separate becoming more
common in the future, in which case we might create, say,
decl-common.c.

C is still implicitly enabled in --enable-languages because we still
require it to bootstrap.  It is still special in this sense, but I
would hope we can reduce the C-isms in other parts of the compiler,
e.g. the semantics of trees.

Neil.

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On Mon, 19 Nov 2001, Neil Booth wrote:

> Things common to C++ as well as C/ObjC, like c-lex.c, c-format.c and
> c-common.c are debatable, but IMO should go there too.  For clarity, I

What about builtin-types.def, builtin-attrs.def (which are also
C/C++/ObjC-specific)?

Would the directory have its own Makefile fragment, or would it use the
gcc Makefile.in?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Neil Booth]

Joseph S. Myers wrote:-

> What about builtin-types.def, builtin-attrs.def (which are also
> C/C++/ObjC-specific)?

Well, them too.  I didn't list every file.

> Would the directory have its own Makefile fragment, or would it use the
> gcc Makefile.in?

I imagine it would have its own, but I'm not an expert on cleanliness
of the Makefiles; Zack might have a different opinion.

Neil.

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Alexandre Oliva]

On Nov 19, 2001, "Joseph S. Myers" <jsm28@cam.ac.uk> wrote:

> On Mon, 19 Nov 2001, Phil Edwards wrote:
>> The usual objection to this is that it makes CVS history browsing more
>> difficult,e.g., the problems discussed in
>> 
>> http://www.cvshome.org/docs/manual/cvs_7.html#SEC66
>> 
>> No matter which of the two or three methods of moving files we use, at
>> least one CVS operation will be much harder.

> It's established that we only ever use cvs add / cvs remove, and don't do
> anything directly in the repository except for bulk imports of directories
> previously maintained in CVS elsewhere (e.g. libjava).

It would be extremely beneficial, I'd strongly suggest us to break
this rule in the case of moving the C-specific sources in the GCC
repository.  It would be best to copy all C-specific CVS files to the
`c' sub-directory, such that you can still do CVS diffs based on
dates, but deleting all tags from it, since they were not present in
older releases.  Of course, if you check out an old snapshot by date,
you'll get additional files in the `c' directory that weren't present
back then, but they wouldn't be used at all, because the Makefile
fragment for the C language wouldn't be present.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On 20 Nov 2001, Alexandre Oliva wrote:

> It would be extremely beneficial, I'd strongly suggest us to break
> this rule in the case of moving the C-specific sources in the GCC
> repository.  It would be best to copy all C-specific CVS files to the
> `c' sub-directory, such that you can still do CVS diffs based on
> dates, but deleting all tags from it, since they were not present in
> older releases.  Of course, if you check out an old snapshot by date,
> you'll get additional files in the `c' directory that weren't present
> back then, but they wouldn't be used at all, because the Makefile
> fragment for the C language wouldn't be present.

Doing this thing is a recipe for problems, even if you mark all the old
revisions "dead" and take care to avoid a file ending up both in and out
of the Attic.  We haven't done it when moving runtime libraries out to
toplevel, we haven't done it when moving docs to the "doc" subdirectory,
we shouldn't make this case any different.  It should suffice to ensure
that the log message names the old and new names for each file and that
there are no other substantive changes (other than the move and changes of
names of included headers) to the moved files in that commit.

Some more advanced version control systems might support renaming files in
a better way, but with CVS we should avoid going behind its back.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Phil Edwards]

On Tue, Nov 20, 2001 at 08:56:31AM +0000, Joseph S. Myers wrote:
> On 20 Nov 2001, Alexandre Oliva wrote:
> > It would be extremely beneficial, I'd strongly suggest us to break
> > this rule in the case of moving the C-specific sources in the GCC
> > repository.  It would be best to copy all C-specific CVS files to the
> > `c' sub-directory, such that you can still do CVS diffs based on
> 
> Doing this thing is a recipe for problems, even if you mark all the old
> revisions "dead" and take care to avoid a file ending up both in and out
> of the Attic.  We haven't done it when moving runtime libraries out to
> toplevel, we haven't done it when moving docs to the "doc" subdirectory,
> we shouldn't make this case any different.

A raw repository shuffle?  We did it when libstdc++-v3 was moved into the
GCC repo.  Hasn't been any difficulty for us.  (Okay, granted, there have
been times when I wished we'd kept the old repo around for 'annotate',
but that's not an issue here.)


> Some more advanced version control systems might support renaming files in
> a better way, but with CVS we should avoid going behind its back.

If it's a documented procedure in the CVS manual, you can hardly call it
"going behind its back."  Yes, I realize that it's a repository-affecting
action that doesn't get logged in CVSROOT/history, but I think it would
be better to preserve individual file history by moving the ,v directly.
The add&remove method is semantically cleaner, but every C front end file
would then be at revision 1.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[David O'Brien]

On Mon, Nov 19, 2001 at 12:27:45PM -0500, Phil Edwards wrote:
> On Sun, Nov 18, 2001 at 04:59:53PM +0000, Neil Booth wrote:
> > c-lang.c is C only.  I think it would be good to create a C directory
> > for the C front end to dispel confusion like this.  It might also help
> > towards making C just another front end, rather than the somewhat
> > special status it currently has.  What do you think Joseph?
> 
> The usual objection to this is that it makes CVS history browsing more
> difficult,e.g., the problems discussed in
> 
>     http://www.cvshome.org/docs/manual/cvs_7.html#SEC66
> 
> No matter which of the two or three methods of moving files we use, at
> least one CVS operation will be much harder.

It is trival.  Do a repository copy.
    cd /cvs/gcc/gcc
    mkdir c
    cd c
    cp ../foo.c,v .
    #run script to prefix tags with "old_"
    cd /tmp
    cvs co gcc
    cd gcc/gcc/
    cvs rm -f foo.c
    cvs ci foo.c
    cd c
    cvs ci -f -m 'repo copied from gcc/gcc/' *


#! /bin/sh

# Recursive function so that the tags are done in reverse order.  That
# makes them come out in the same order in the final file.
fix() {
    local file tag

    if [ $# -le 1 ]; then
	return
    fi
    file=$1
    tag=$2
    shift 2
    fix $file $* || exit
    new=old_$tag
    echo "  $tag ==> $new"
    rcs -q -n${new}:${tag} $file || exit
    rcs -q -n${tag} $file || exit
}

ecmd=cat
icmd=cat

while getopts "e:i:" opt; do
    case $opt in
    e) ecmd="fgrep -f $OPTARG -x -v";;
    i) icmd="fgrep -f $OPTARG -x";;
    *) echo "Usage: $(basename $0) [-e excludefrom] [-i includefrom] file..."
       exit 1;;
    esac
done
shift $(($OPTIND-1))

for file; do
    echo $file:
    tags=$(rlog -h $file | grep '^	' | grep -v '^	old' |\
	sed -e 's/^	\([^:]*\):.*$/\1/' | $ecmd | $icmd)
    fix $file $tags
done

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[David O'Brien]

On Tue, Nov 20, 2001 at 01:14:42AM -0200, Alexandre Oliva wrote:
> It would be best to copy all C-specific CVS files to the
> `c' sub-directory, such that you can still do CVS diffs based on
> dates, but deleting all tags from it, since they were not present in
> older releases.

You *really* don't want to remove tags as that is part of the history and
timeline.  There are times the tags can give a lot of implied data.
Instead rename the tags (in FreeBSD we prefix them with "old_").

-- 
-- David  (obrien@FreeBSD.org)

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[David O'Brien]

On Mon, Nov 19, 2001 at 05:38:43PM +0000, Joseph S. Myers wrote:
> It's established that we only ever use cvs add / cvs remove, and don't do
> anything directly in the repository except for bulk imports of directories
> previously maintained in CVS elsewhere (e.g. libjava).

Why?  CVS as a SCM tool stinks, and w/o repo copies it is an order of
magnitude suckier.  FreeBSD has *extensive* experience with repo copies.
They work fine.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[David O'Brien]

On Tue, Nov 20, 2001 at 08:56:31AM +0000, Joseph S. Myers wrote:
> On 20 Nov 2001, Alexandre Oliva wrote:
> > It would be extremely beneficial, I'd strongly suggest us to break
> > this rule in the case of moving the C-specific sources in the GCC
> > repository.  It would be best to copy all C-specific CVS files to the
> > `c' sub-directory, such that you can still do CVS diffs based on
> > dates, but deleting all tags from it, since they were not present in
> > older releases.  Of course, if you check out an old snapshot by date,
> > you'll get additional files in the `c' directory that weren't present
> > back then, but they wouldn't be used at all, because the Makefile
> > fragment for the C language wouldn't be present.
> 
> Doing this thing is a recipe for problems, even if you mark all the old
> revisions "dead" and take care to avoid a file ending up both in and out
> of the Attic.

Specifics of the potenital problems?  FreeBSD has been doing this for
many, many years.

> Some more advanced version control systems might support renaming files in
> a better way, but with CVS we should avoid going behind its back.

Why?
 
-- 
-- David  (obrien@FreeBSD.org)

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[David O'Brien]

On Wed, Nov 21, 2001 at 12:26:17AM +0000, Joseph S. Myers wrote:
> > and w/o repo copies it is an order of
> > magnitude suckier.  FreeBSD has *extensive* experience with repo copies.
> > They work fine.
> 
> You have, for example, always avoided the problem with files both in and
> out of Attic noted at:
> 
> http://mail-index.netbsd.org/tech-misc/2001/08/08/0000.html

Yes.  I have never seen that problem in the FreeBSD CVS repository.
I do not know how those got created in the NetBSD repository.
 
> The essential problem - if you avoid such pitfalls as this - is that it
> creates a *false* history - it claims a file to have been present in some
> given directory with a given name, having had given changes made to it,
> when it wasn't.  

> It also only deals with one very specific problem, that
> of a whole file being moved, 

Yes.  And in this thread that is the specific problem -- wanting to move
a file.

> not of the common case of a large amount of
> text from one file being moved to another.

True, that would not be a repo copy, unless you are spliting foo.c into
foo1.c and foo2.c.  In which case sometimes we would copy foo.c,v to both
foo1.c,v and foo2.c,v.  Then using normal editor and CVS operations cut
foo{1,2}.c down to what they should be; commit them (noting the repo
copied happened) and cvs rm foo.c.

History is kept (and tags are sane if you the script I supplied), and
there is no weirdness in the repo directory.

> You could always adapt CVS
> to allow direct diffing between given revisions of different files without
> needing to copy ,v files or check out those specific revisions.

I'd love to see the patches.  But until they exist, repo copies are what
is available.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On Tue, 20 Nov 2001, David O'Brien wrote:

> Why?  CVS as a SCM tool stinks,

Yes.

> and w/o repo copies it is an order of
> magnitude suckier.  FreeBSD has *extensive* experience with repo copies.
> They work fine.

You have, for example, always avoided the problem with files both in and
out of Attic noted at:

http://mail-index.netbsd.org/tech-misc/2001/08/08/0000.html

?

The essential problem - if you avoid such pitfalls as this - is that it
creates a *false* history - it claims a file to have been present in some
given directory with a given name, having had given changes made to it,
when it wasn't.  It also only deals with one very specific problem, that
of a whole file being moved, not of the common case of a large amount of
text from one file being moved to another.

I haven't found difficulty in using the history of documentation files
that is partly in gcc/ and partly in gcc/doc/.  You could always adapt CVS
to allow direct diffing between given revisions of different files without
needing to copy ,v files or check out those specific revisions.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On Tue, 20 Nov 2001, Phil Edwards wrote:

> A raw repository shuffle?  We did it when libstdc++-v3 was moved into the
> GCC repo.  Hasn't been any difficulty for us.  (Okay, granted, there have
> been times when I wished we'd kept the old repo around for 'annotate',
> but that's not an issue here.)

I thought the old libstdc++ repository was still around for CVS and rsync
(as well as in old-releases/old-cvs on the FTP site).  libstdc++ was a
case of adding the new files without doing anything special with ,v files,
whereas with libjava the ,v files were copied.

> action that doesn't get logged in CVSROOT/history, but I think it would
> be better to preserve individual file history by moving the ,v directly.
> The add&remove method is semantically cleaner, but every C front end file
> would then be at revision 1.

I don't see the files being at revision 1 as a problem.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Phil Edwards]

On Wed, Nov 21, 2001 at 12:31:06AM +0000, Joseph S. Myers wrote:
> On Tue, 20 Nov 2001, Phil Edwards wrote:
> > The add&remove method is semantically cleaner, but every C front end file
> > would then be at revision 1.
> 
> I don't see the files being at revision 1 as a problem.

Sorry, let me clarify:  being at revision 1 isn't a problem in itself.

What I meant was all that "revision 1" implies: 'log' and 'annotate'
are reset, for example.

If the ,v files are moved, those commands continue to just work.  Otherwise a
GCC hacker can only 'log' and 'annotate' back so far before being forced
to find an old checkout of the repo and repeating the work there.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On Tue, 20 Nov 2001, Phil Edwards wrote:

> What I meant was all that "revision 1" implies: 'log' and 'annotate'
> are reset, for example.
>
> If the ,v files are moved, those commands continue to just work.  Otherwise a
> GCC hacker can only 'log' and 'annotate' back so far before being forced
> to find an old checkout of the repo and repeating the work there.

CVS annotate and log work just fine on files that have been cvs removed;
try them on gcc/gcc.texi, for example.  No old checkout is required.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Phil Edwards]

On Tue, Nov 20, 2001 at 05:13:15PM -0800, Zack Weinberg wrote:
> I say if we wait about another six months Subversion[1] will be usable
> enough that we can scrap CVS, and then we'll have a version control
> system that actually understands renaming files.

Wow, are they that far along?  It's been a while since I looked...  Shoot,
if Subversion is a viable replacement within the next several months,
I'm more than willing to wait.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Zack Weinberg]

On Mon, Nov 19, 2001 at 12:27:45PM -0500, Phil Edwards wrote:
> On Sun, Nov 18, 2001 at 04:59:53PM +0000, Neil Booth wrote:
> > c-lang.c is C only.  I think it would be good to create a C directory
> > for the C front end to dispel confusion like this.  It might also help
> > towards making C just another front end, rather than the somewhat
> > special status it currently has.  What do you think Joseph?
> 
> The usual objection to this is that it makes CVS history browsing more
> difficult,e.g., the problems discussed in
> 
>     http://www.cvshome.org/docs/manual/cvs_7.html#SEC66
> 
> No matter which of the two or three methods of moving files we use, at
> least one CVS operation will be much harder.

I say if we wait about another six months Subversion[1] will be usable
enough that we can scrap CVS, and then we'll have a version control
system that actually understands renaming files.

zw

[1] http://subversion.tigris.org/ IIRC

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Alexandre Oliva]

On Nov 20, 2001, "Joseph S. Myers" <jsm28@cam.ac.uk> wrote:

> On Tue, 20 Nov 2001, Phil Edwards wrote:
>> What I meant was all that "revision 1" implies: 'log' and 'annotate'
>> are reset, for example.
>> 
>> If the ,v files are moved, those commands continue to just work.  Otherwise a
>> GCC hacker can only 'log' and 'annotate' back so far before being forced
>> to find an old checkout of the repo and repeating the work there.

> CVS annotate and log work just fine on files that have been cvs removed;
> try them on gcc/gcc.texi, for example.  No old checkout is required.

Do you have any script handy that merges CVS annotate from two
different files, such that, if one line is marked as from revision 1,
it takes the line from the other?  This would be necessary to give
developers the same amount of information from cvs annotate without
too much additional effort.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Zack Weinberg]

On Tue, Nov 20, 2001 at 08:25:54PM -0500, Phil Edwards wrote:
> On Tue, Nov 20, 2001 at 05:13:15PM -0800, Zack Weinberg wrote:
> > I say if we wait about another six months Subversion[1] will be usable
> > enough that we can scrap CVS, and then we'll have a version control
> > system that actually understands renaming files.
> 
> Wow, are they that far along?  It's been a while since I looked...  Shoot,
> if Subversion is a viable replacement within the next several months,
> I'm more than willing to wait.

Yeah, they're on track to have something viable around the same time
we kick 3.1 out the door.  The status page says that they're at 0.6,
with "svn mv" and "svn cp" already working on files, and lists
upcoming releases:

    * Subversion 0.7 (Mon 3 Dec 2001): Branching and tagging.

    * Subversion 0.8 (Thu 20 Dec 2001): "Simple" merging
      (ancestry-sensitive merging is optional for this
      milestone). Diffs on network in both directions.

    * Alpha (TBD): Most commonly used features completed.

    * Beta (TBD): Release candidate, heavy testing. Possible inclusion
      of newer, less popular features.

    * 1.0 Release (TBD): Release.

I'm a bit nervous about the number of weird libraries with unstable
interfaces they want (neon, APR), and wonder if the client will wind
up being as portable as we need it to be.  They do seem aware of the
issues, and they've got *BSD people on the team so at least it won't
be all-the-world-is-Linux crap.

When they get to beta I may do some trial conversions of our existing
repository, time permitting.

zw

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On Tue, 20 Nov 2001, David O'Brien wrote:

> #! /bin/sh

This doesn't look like it marks the old revisions in the copied file dead.
Shouldn't it (so they don't appear in dated checkouts)?

>     tags=$(rlog -h $file | grep '^	' | grep -v '^	old' |\

Is parsing rlog output to extract tags reliable (given that parsing it to
extract log messages and revision information definitely isn't)?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

On Tue, 20 Nov 2001, Zack Weinberg wrote:

> I'm a bit nervous about the number of weird libraries with unstable
> interfaces they want (neon, APR), and wonder if the client will wind
> up being as portable as we need it to be.  They do seem aware of the
> issues, and they've got *BSD people on the team so at least it won't
> be all-the-world-is-Linux crap.

Also, is the BerkeleyDB file format used in repositories stable long-term
between BerkeleyDB releases?

Some obvious questions that the "Subversion for CVS Users" page doesn't
cover are:

* What's the equivalent of cvs -z<n> (link compression)?  In general, how
do the bandwidth-efficiency of checkouts and updates compare between CVS
and Subversion?

* What's the Subversion equivalent of CVS-over-SSH?

* What's the Subversion equivalent of cvsweb, and is there one available
in which the Subversion sources and their history can be browsed?

> When they get to beta I may do some trial conversions of our existing
> repository, time permitting.

It ought to be possible to teach the conversion program about the idiom of
cvs remove / cvs add to rename files (allowing for complications such as
the file having changed when it was renamed and the file having been
renamed at different times on different branches), given a list of (old
name, new name) pairs (which could be constructed, mostly completely, when
necessary by examining the current Attics).  Given this there's no need to
hold off moving files on the basis that Subversion will make it easier
(and in general I think holding off work on the basis that some other
piece of software (independent of GCC) will, through code that hasn't yet
been written or stabilized, make things easier at some future point, is a
bad idea - when Subversion is in fact ready, not when it's predicted to 
be ready, we can then deal with the conversion).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Branko Čibej]

Zack Weinberg wrote:

>On Tue, Nov 20, 2001 at 08:25:54PM -0500, Phil Edwards wrote:
>
>>On Tue, Nov 20, 2001 at 05:13:15PM -0800, Zack Weinberg wrote:
>>
>>>I say if we wait about another six months Subversion[1] will be usable
>>>enough that we can scrap CVS, and then we'll have a version control
>>>system that actually understands renaming files.
>>>
>>Wow, are they that far along?  It's been a while since I looked...  Shoot,
>>if Subversion is a viable replacement within the next several months,
>>I'm more than willing to wait.
>>

We're pretty far along the road. We've been self-hosting for about two 
months now, without major problems (and no data loss).

>Yeah, they're on track to have something viable around the same time
>we kick 3.1 out the door.  The status page says that they're at 0.6,
>with "svn mv" and "svn cp" already working on files, and lists
>upcoming releases:
>
>    * Subversion 0.7 (Mon 3 Dec 2001): Branching and tagging.
>
>    * Subversion 0.8 (Thu 20 Dec 2001): "Simple" merging
>      (ancestry-sensitive merging is optional for this
>      milestone). Diffs on network in both directions.
>
>    * Alpha (TBD): Most commonly used features completed.
>
>    * Beta (TBD): Release candidate, heavy testing. Possible inclusion
>      of newer, less popular features.
>
>    * 1.0 Release (TBD): Release.
>
>I'm a bit nervous about the number of weird libraries with unstable
>interfaces they want (neon, APR),
>
APR is shared by Apache 2.0, and will be release-quality long before 
Subversion.
Neon is a bit different

> and wonder if the client will wind
>up being as portable as we need it to be.
>
The client has been tested on at least 13 different platfotms to date. 
You can get the list directly from the SVN repository on 
http://svn.collab.net/repos/svn/trunk/PORTING, although note that it's 
not quite up-to-date.
 

>  They do seem aware of the
>issues, and they've got *BSD people on the team so at least it won't
>be all-the-world-is-Linux crap.
>
Heh. I 've been doing all my development with MSVC on Windows lately, so 
we're also safe from the all-the-world-is-gcc crap. :-)

>When they get to beta I may do some trial conversions of our existing
>repository, time permitting.
>
We'll need a converter for that. cvs2svn is planned (for Beta, I think), 
but it's not very far along. Volunteers are welcome. :-)


-- 
Brane Ăˆibej   <brane@xbc.nu>   http://www.xbc.nu/brane/

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Phil Edwards]

On Wed, Nov 21, 2001 at 11:14:38AM +0000, Joseph S. Myers wrote:
> Also, is the BerkeleyDB file format used in repositories stable long-term
> between BerkeleyDB releases?

http://www.sleepycat.com/update/index.html

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Mark Mitchell]

> If it's a documented procedure in the CVS manual, you can hardly call it
> "going behind its back."  Yes, I realize that it's a repository-affecting
> action that doesn't get logged in CVSROOT/history, but I think it would
> be better to preserve individual file history by moving the ,v directly.
> The add&remove method is semantically cleaner, but every C front end file
> would then be at revision 1.

If we just "mv" the files, we will never be able to check out old
branches.

I don't think we have a choice; we need to "cvs remove; cvs add".

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Sam TH]

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Wed, Nov 21, 2001 at 11:14:38AM +0000, Joseph S. Myers wrote:
> On Tue, 20 Nov 2001, Zack Weinberg wrote:
> 
> > I'm a bit nervous about the number of weird libraries with unstable
> > interfaces they want (neon, APR), and wonder if the client will wind
> > up being as portable as we need it to be.  They do seem aware of the
> > issues, and they've got *BSD people on the team so at least it won't
> > be all-the-world-is-Linux crap.

As to the wierd libraries, they will certainly be stable by the time
SVN is (which I'm not sure will be in the next 6 months).  I think
neon can currently be relied upon, and APR will be a part of Apache
2.0 when that is released (which should be soon, I think).  

> 
> Also, is the BerkeleyDB file format used in repositories stable long-term
> between BerkeleyDB releases?

It is stable between compatible DB releases, and upgrades nicely (with
no effect on the client) when not.  

> 
> Some obvious questions that the "Subversion for CVS Users" page doesn't
> cover are:
> 
> * What's the equivalent of cvs -z<n> (link compression)?  In general, how
> do the bandwidth-efficiency of checkouts and updates compare between CVS
> and Subversion?

It's all compressed, and it's way better, in answer to those two
questions.  

> 
> * What's the Subversion equivalent of CVS-over-SSH?
> 

Eventually SVN will be able to use HTTPS, just as any other apache
server can.  I don't know of concret plans to implement encryption in
the client at the moment, but I expect it to be done in a reasonable
timeframe.  

> * What's the Subversion equivalent of cvsweb, and is there one available
> in which the Subversion sources and their history can be browsed?
> 

There isn't one yet, but the author of webcvs (a cvsweb replacement in
python) is one of the lead SVN developers.  


           
sam th --- sam@uchicago.edu --- http://www.abisource.com/~sam/
OpenPGP Key: CABD33FC --- http://samth.dyndns.org/key
DeCSS: http://samth.dynds.org/decss


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Phil Edwards]

On Wed, Nov 21, 2001 at 11:21:48AM -0600, Sam TH wrote:
> > * What's the Subversion equivalent of CVS-over-SSH?
> 
> Eventually SVN will be able to use HTTPS, just as any other apache
> server can.

Ugh.  I know of a few sites (mine included) where outgoing HTTPS goes under
much more scrutiny, filtering, blocking, and redirection than outgoing
SSH does.


> I don't know of concret plans to implement encryption in
> the client at the moment, but I expect it to be done in a reasonable
> timeframe.  

It doesn't need to [re-]implement encryption.  It just needs to be able
to be tunnelled, like CVS/FTP/X11/RCP/NFS.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Stan Shebs]

Mark Mitchell wrote:
> 
> > If it's a documented procedure in the CVS manual, you can hardly call it
> > "going behind its back."  Yes, I realize that it's a repository-affecting
> > action that doesn't get logged in CVSROOT/history, but I think it would
> > be better to preserve individual file history by moving the ,v directly.
> > The add&remove method is semantically cleaner, but every C front end file
> > would then be at revision 1.
> 
> If we just "mv" the files, we will never be able to check out old
> branches.
> 
> I don't think we have a choice; we need to "cvs remove; cvs add".

I agree.  "It's not nice to fool Mother CVS." :-)

I'm not clear on the benefit of moving the C frontend right now.
The original rationales for leaving it alone when the C++ frontend
was moved into a subdir were that a) it was required to bootstrap,
and b) there weren't enough files to bother.  Now that there are
more frontends, the symmetry argument is stronger than it used to
be...

One thing to think about that is that there is the idea (not
sure if it's official roadmap) to integrate all the C dialects
into a single frontend that chooses dialect dynamically.  If
that happens, we'll probably want all the c-*, cp/*, and objc/*
to live together in a single c/ subdir.  Since there will be
much churning at that time, it might be better to move everything
as a side effect of rewriting contents.

Stan

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Zack Weinberg]

On Wed, Nov 21, 2001 at 05:30:39PM -0500, Phil Edwards wrote:
> > I don't know of concret plans to implement encryption in
> > the client at the moment, but I expect it to be done in a reasonable
> > timeframe.  
> 
> It doesn't need to [re-]implement encryption.  It just needs to be able
> to be tunnelled, like CVS/FTP/X11/RCP/NFS.

I suspect that SSH port forwarding could be used for this, e.g.

$ ssh -N -L 8888:subversion.server.example.com:80

zw

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 2050 bytes --]

On Wed, 21 Nov 2001, Branko [ISO-8859-2] Èibej wrote:

> >When they get to beta I may do some trial conversions of our existing
> >repository, time permitting.
> >
> We'll need a converter for that. cvs2svn is planned (for Beta, I think), 
> but it's not very far along. Volunteers are welcome. :-)

Can the Subversion version model handle multiple past development
mainlines merging into one future mainline?

We have at present the separate "gcc" and "src" repositories, which share
some files - and some people would like to merge these into a single
repository, but it would be desirable still to be able to check out either
past tree on any tag or date from before the merge.  If Subversion
supports this, conversion to Subversion would be a natural time to do the
merge (since people would need to replace their working directories anyway
at that time).

That is, we'd have

                      gcc 3.1 branch ---
                      /
                     /
----- gcc mainline ----------\
                              ------ merged single mainline in SVN
----- src mainline ----------/
                    \
                     \
                      binutils 2.12 branch ---

and would want all of the merged single mainline and the past branches
from the individual trees pre-merge to work.  (Presuming that before such
a merge, all differences in common files are resolved and they are
maintained in sync - though files deleted in the past in one or both trees
might differ.)

Can this be done in Subversion?  If not, it might still be the appropriate
time to merge the repositories - but starting from only one repository's
,v file for each file that is or has been in both, putting copies of both
repositories up for FTP in the appropriate old-releases directories (as
should be done anyway at the time of the change), and manually touching up
the files taken from one tree to have appropriate versions for the
branches active in the other tree.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Zack Weinberg]

On Wed, Nov 21, 2001 at 11:15:54PM +0000, Joseph S. Myers wrote:
> 
> Can the Subversion version model handle multiple past development
> mainlines merging into one future mainline?
> 
> We have at present the separate "gcc" and "src" repositories, which share
> some files - and some people would like to merge these into a single
> repository, but it would be desirable still to be able to check out either
> past tree on any tag or date from before the merge.

There's a related problem, which we have now with CVS in the src
repository, but would get worse if they were merged.  CVS does not
remember which module(s) you originally selected when you checked out
a tree.  Therefore, if you use the -d option, it checks out the entire
repository the first time you try to update a working copy containing
a subset of the tree.  But if you don't use the -d option you don't
get _any_ new subdirectories unless you specifically ask for them, and
you may not know which they are.

It would be nice if Subversion did this better.

zw

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Karl Fogel]

Hmmm.  Joseph, I *think* I understand your question below... But would
you mind re-asking with a small, concrete example tree?  Then we can
use the dirs and files in that tree to a) make sure we've completely
understood the question, and b) answer it accurately.

Thanks,
-Karl


"Joseph S. Myers" <jsm28@cam.ac.uk> writes:
> On Wed, 21 Nov 2001, Branko [ISO-8859-2] Èibej wrote:
> 
> > >When they get to beta I may do some trial conversions of our existing
> > >repository, time permitting.
> > >
> > We'll need a converter for that. cvs2svn is planned (for Beta, I think), 
> > but it's not very far along. Volunteers are welcome. :-)
> 
> Can the Subversion version model handle multiple past development
> mainlines merging into one future mainline?
> 
> We have at present the separate "gcc" and "src" repositories, which share
> some files - and some people would like to merge these into a single
> repository, but it would be desirable still to be able to check out either
> past tree on any tag or date from before the merge.  If Subversion
> supports this, conversion to Subversion would be a natural time to do the
> merge (since people would need to replace their working directories anyway
> at that time).
> 
> That is, we'd have
> 
>                       gcc 3.1 branch ---
>                       /
>                      /
> ----- gcc mainline ----------\
>                               ------ merged single mainline in SVN
> ----- src mainline ----------/
>                     \
>                      \
>                       binutils 2.12 branch ---
> 
> and would want all of the merged single mainline and the past branches
> from the individual trees pre-merge to work.  (Presuming that before such
> a merge, all differences in common files are resolved and they are
> maintained in sync - though files deleted in the past in one or both trees
> might differ.)
> 
> Can this be done in Subversion?  If not, it might still be the appropriate
> time to merge the repositories - but starting from only one repository's
> ,v file for each file that is or has been in both, putting copies of both
> repositories up for FTP in the appropriate old-releases directories (as
> should be done anyway at the time of the change), and manually touching up
> the files taken from one tree to have appropriate versions for the
> branches active in the other tree.
> 
> -- 
> Joseph S. Myers
> jsm28@cam.ac.uk
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Karl Fogel]

Zack Weinberg <zack@codesourcery.com> writes:
> There's a related problem, which we have now with CVS in the src
> repository, but would get worse if they were merged.  CVS does not
> remember which module(s) you originally selected when you checked out
> a tree.  Therefore, if you use the -d option, it checks out the entire
> repository the first time you try to update a working copy containing
> a subset of the tree.  But if you don't use the -d option you don't
> get _any_ new subdirectories unless you specifically ask for them, and
> you may not know which they are.
> 
> It would be nice if Subversion did this better.

I'm not sure it does (yet), except in that it versions directories,
but I don't think that exactly solves what you're talking about.

There have been various proposals for a Subversion module system,
along the lines of "union directories", or other indirection-based
systems that allow rule-based groupings.  That would probably solve
the problem described above, but it will not be in 1.0.

On the other hand, Subversion will support symlinks / shortcuts, which
should alleviate the problem...

-K

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1607 bytes --]

On 21 Nov 2001, Karl Fogel wrote:

> Hmmm.  Joseph, I *think* I understand your question below... But would
> you mind re-asking with a small, concrete example tree?  Then we can
> use the dirs and files in that tree to a) make sure we've completely
> understood the question, and b) answer it accurately.

Attached is a tarball with two directories, tree1 and tree2, each
containing a single file,v file.  These files started out of sync, were
changed somewhat, had release branches made (which we suppose are still
active and we might want to make further changes in future), had further
changes on the release branches, then were synchronised on the mainline.
This represents the situation for any file shared between the src and gcc
CVS trees.

What's wanted is to merge them, so that for future development there's a
single mainline that won't get out of sync, but so that all of the
following are also still possible:

* Making changes to the release branch on tree1 or tree2.
* Checking out any past tag or branch from tree1 or tree2.
* Checking out tree1 as of any given date, or tree2 as of any given date.
* Reading the logs for the history of the file in either tree1 or tree2.

As variants, the following cases may also occur:

* A file that was deleted and in the Attic in one tree, but present in the 
other.

* A file that was deleted in both trees and may or may not have had
different contents in each tree when deleted.

* Either of these also applies for files in the Attic not because of
deletion but because of having only been created on a branch.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 613 bytes --]

Re: Moving C to its own directory (was Re: ObjC tree inlining)

[Zack Weinberg]

On Wed, Nov 21, 2001 at 05:58:54PM -0600, Karl Fogel wrote:
> 
> There have been various proposals for a Subversion module system,
> along the lines of "union directories", or other indirection-based
> systems that allow rule-based groupings.  That would probably solve
> the problem described above, but it will not be in 1.0.
> 
> On the other hand, Subversion will support symlinks / shortcuts, which
> should alleviate the problem...

Let me attempt to illustrate how GCC currently uses modules and how I
think that might map to a subversion repository, and you can tell me
if I'm all wet.

The gcc tree is laid out like this:

/cvs/gcc/gcc/		# core code needed always
	 libiberty/
	 include/
	 configure
	 ...

	 gcc/cp/	# C++ front end and libraries
	 libstdc++/

	 gcc/java/	# Java front end and libraries
	 libjava/
	 boehm-gc/
	 ...

Each of these blocks is a CVS module: checking out gcc-core gets you
no more than you need to build a C compiler, gcc-core + gcc-cp gets
you C++ as well, etc.  Checking out "gcc" gives you the whole
enchilada.

Now, you say Subversion doesn't have a feature directly equivalent to
CVS modules, but it does have in-repository symbolic links.  I could
lay out the file system like this:

/subv/gcc/PHYSICAL/libiberty/
		   include/
		   gcc-core/
		   gcc-cp/
		   gcc-java/
		   libstdc++/
		   libjava/
		   ...

/subv/gcc/all/  libiberty -> ../PHYSICAL/libiberty
		gcc       -> ../PHYSICAL/gcc-core
		gcc/cp    -> ../../PHYSICAL/gcc-cp
		...

/subv/gcc/core/ libiberty -> ../PHYSICAL/libiberty
		gcc       -> ../PHYSICAL/gcc-core
		...

And ideally, when I checked out "all" or "core", the server would
traverse the symlinks and I'd get a working copy that appeared to have
the cp directory as a direct child of gcc/.  Also, on future update
operations, the server would notice additions to the shadow tree I'm
in, but not pick up PHYSICAL modules not referenced from that tree.

Two problems:  first, I've got a symlink as a child of a symlink in
the above illo, which is probably impossible.  Second, how do I check
out "gcc-core gcc-cp" and get just the core and the C++ compiler?  We
don't want a combinatorial explosion of these shadow trees.

zw