gcc-4.8.x import

[Christos Zoulas]

Hello,

As some of you are aware, we've been working on getting gcc-4.8.x
working on NetBSD with plans to import it before the branch to netbsd-7.
Our ambitious goal was to import on top of gcc4.5 in
/usr/src/external/gpl3/gcc, but this all-or-nothing approach has
proven to be more difficult than we anticipated, largely because
it is difficult to test everything and some platforms (sh3) are
still not working very well. The fallback plan to go to gcc-4.1.3
for platforms that don't work with gcc-4.8.x, is not a very good
one as this compiler is getting too old to be useful (many bugs
have not been fixed and lacks many of the recent flag/warning
additions).

The biggest problem with importing another gcc copy in the tree
is size, but it looks like because vax is working we'll be able
to delete gcc-4.1.3 from /usr/src/gnu/dist and this means that
we can mostly migrate away from /usr/src/gnu the rest of the
stuff and /usr/src/gnu can go away (everything migrated to external).
Unrelated to the gcc stuff, but /usr/src/dist is almost gone too -
the only thing left is pf which needs an upgrade or deletion.

The current plan is to keep two versions of gcc in the tree; the
previous one and the current one. By importing the gcc-4.8.x in
/usr/src/external/gpl3/{cgg,ccg,yagcc} (pick one) we can bounce
back and forth between that directory and /usr/src/external/gpl3/gcc.

The other advantage of having two trees right now is that some
ppc archtectures have been obsoleted and we need to figure out
how to do with them. This gives us more time.

So pick a name, and we'll be importing the next gcc in the next
few days.

I would like to thank martin, mrg, nisimura, skrll for all the
work they put in this.

Best,

christos

[Greg Troxel]

Post by Christos Zoulas
The current plan is to keep two versions of gcc in the tree; the
previous one and the current one. By importing the gcc-4.8.x in
/usr/src/external/gpl3/{cgg,ccg,yagcc} (pick one) we can bounce
back and forth between that directory and /usr/src/external/gpl3/gcc.

This sounds reasonable to me. My general opinion, based on pkgsrc where
situations like this arise all the time, is to decide either

the world is such that only one copy will ever be needed ==> just use
the name

sometimes >1 copy will be needed ==> always use version suffix

and also try not to rename existing packages/directories, because the
cost of renaming is usually worse than the benefit of purity.

So this says the new directory should be

/usr/src/external/gpl3/gcc48

which will be unconfusing. Later, we might add gcc49 and remove the
plain gcc.

[Christos Zoulas]

On Feb 18, 10:04am, ***@ir.bbn.com (Greg Troxel) wrote:
-- Subject: Re: gcc-4.8.x import

| So this says the new directory should be
|
| /usr/src/external/gpl3/gcc48
|
| which will be unconfusing. Later, we might add gcc49 and remove the
| plain gcc.

In a perfect world where the cost of adding new files and directories to VCS
(CVS ATM) is reasonable... Unfortunately this is not a perfect world.

christos

[Greg Troxel]

Post by Christos Zoulas
-- Subject: Re: gcc-4.8.x import
| So this says the new directory should be
|
| /usr/src/external/gpl3/gcc48
|
| which will be unconfusing. Later, we might add gcc49 and remove the
| plain gcc.
In a perfect world where the cost of adding new files and directories to VCS
(CVS ATM) is reasonable... Unfortunately this is not a perfect world.

So I thought that I only said "please call it gcc48, not yagcc or
something else that's hard to understand". I don't see how that leads
to more files than what you were proposing.

[David Holland]

Post by Greg Troxel
So I thought that I only said "please call it gcc48, not yagcc or
something else that's hard to understand". I don't see how that leads
to more files than what you were proposing.

Every time gcc gets imported in a new place, it creates a monster
subtree on the CVS server that never goes away and has to be traversed
in detail on every CVS update. This is already a problem and creating
more and more of these is not a winner.

My inclination is to reuse gnu/dist/gcc4 and treat it as one more
thing that can't be cleaned up fully until we manage to dump CVS.

[Christos Zoulas]

On Feb 19, 10:20am, ***@ir.bbn.com (Greg Troxel) wrote:
-- Subject: Re: gcc-4.8.x import

| So I thought that I only said "please call it gcc48, not yagcc or
| something else that's hard to understand". I don't see how that leads
| to more files than what you were proposing.

Yes so for this cycle it will work. gcc-4.8.x gets imported to gcc48.
The next upgrade it gcc-4.9.x, gets put in gcc. The one after is gcc-4.10.x
where do I put it? In gcc48? Or gcc410? If I put it in gcc48 it does not
make sense anymore, if I put it in gcc410, I create yet another monster
tree.

christos

[Anthony Mallet]

On Wednesday, at 10:38, Christos Zoulas wrote:
| Yes so for this cycle it will work. gcc-4.8.x gets imported to gcc48.
| The next upgrade it gcc-4.9.x, gets put in gcc. The one after is gcc-4.10.x
| where do I put it? In gcc48? Or gcc410? If I put it in gcc48 it does not
| make sense anymore, if I put it in gcc410, I create yet another monster
| tree.

I'm probably missing a lot of background history and former discussions, but
wouldn't it be possible to create more cvs modules to deal with this issue ?

I don't remember exactly the detail of modules in cvs, but couldn't external
be a module, or even external/gpl3/gcc48 ?

[David Laight]

Post by Anthony Mallet
| Yes so for this cycle it will work. gcc-4.8.x gets imported to gcc48.
| The next upgrade it gcc-4.9.x, gets put in gcc. The one after is gcc-4.10.x
| where do I put it? In gcc48? Or gcc410? If I put it in gcc48 it does not
| make sense anymore, if I put it in gcc410, I create yet another monster
| tree.
I'm probably missing a lot of background history and former discussions, but
wouldn't it be possible to create more cvs modules to deal with this issue ?
I don't remember exactly the detail of modules in cvs, but couldn't external
be a module, or even external/gpl3/gcc48 ?

You can't remove the (large) directory tree because you need to be able to
build old releases.

Having 'a' and 'b' trees means that you don't have replications of
unchanged files.
But arranging to alternate between them might be tricky.

What about a gcc_old tree that imports the old version from the 'gcc'
tree (probably as a vendor branch import).

The other option is (somehow) to arrange to checkout a tag for the
builds that can't use HEAD.
Having put down a branch tag (etc) before importing the new version.

David

[David Holland]

Post by David Laight
What about a gcc_old tree that imports the old version from the 'gcc'
tree (probably as a vendor branch import).

That's not a bad idea actually. It will use a bit more space, but
that's not a big deal.

Post by David Laight
The other option is (somehow) to arrange to checkout a tag for the
builds that can't use HEAD.
Having put down a branch tag (etc) before importing the new version.

That kind of stuff can be done with modules, but it would also be a
barrier to moving away from CVS so it probably isn't a good idea.

[Alan Barrett]

Post by Greg Troxel
So I thought that I only said "please call it gcc48, not yagcc or
something else that's hard to understand". I don't see how that leads
to more files than what you were proposing.

There's a bug/limitation in cvs such that use of "cvs update -dP"
or "cvs checkout -P" creates and then deletes any directories that
are present in older or newer revisions of the tree, but are not
present in the current or desired revision. For large subtrees,
this can incur a significant cost in client/server data transfer
and client disk I/O, and it applies to every use of "cvs update"
in every working tree for every user forever after the subtree was
ostensibly deleted.

In pkgsrc, where the subtrees that get deleted are relatively
small, it's much less of an issue. For gcc in the src tree, where
there are more than 5000 subdirectories in src/external/gplv3/gcc,
it may be worth suffering suboptimal naming to reduce the "cvs
update" overhead.

--apb (Alan Barrett)

[David Laight]

Post by Alan Barrett

Post by Greg Troxel
So I thought that I only said "please call it gcc48, not yagcc or
something else that's hard to understand". I don't see how that leads
to more files than what you were proposing.

There's a bug/limitation in cvs such that use of "cvs update -dP"
or "cvs checkout -P" creates and then deletes any directories that
are present in older or newer revisions of the tree, but are not
present in the current or desired revision. For large subtrees,
this can incur a significant cost in client/server data transfer
and client disk I/O, and it applies to every use of "cvs update"
in every working tree for every user forever after the subtree was
ostensibly deleted.

cvs also has a nasty habit of generating a temporary copy of the
entire directory tree on the server side during some operations.
(Although netbsd's copy might have that changed.)

David