Snapshot

Snapshot

[Jeffrey A Law]

Just a note, we're holding up the snapshot so that we can get a libio
patch based on HJ's stuff into the next snapshot.   Hopefully Ulrich
will fix the remaining problems later today/tonight (he's in Germany,
I don't know what kind of hours he usually works) and I'll make a snapshot
as soon as I hear from him.


--
Jeff Law (law@cygnus.com)
Cygnus Solutions		EGCS GNU Compiler System
http://www.cygnus.com		http://www.cygnus.com/egcs

Re: Snapshot

[Joe Buck]

> Just a note, we're holding up the snapshot so that we can get a libio
> patch based on HJ's stuff into the next snapshot.   Hopefully Ulrich
> will fix the remaining problems later today/tonight (he's in Germany,
> I don't know what kind of hours he usually works) and I'll make a snapshot
> as soon as I hear from him.

OK.  Please fix "make install" to clean out $prefix/include/g++ first;
otherwise users are testing a mixture of the current and previous
snapshots.

Re: Snapshot

[Alexandre Oliva]

Joe Buck writes:

> OK.  Please fix "make install" to clean out $prefix/include/g++ first;
> otherwise users are testing a mixture of the current and previous
> snapshots.

this is a bit dangerous, since this directory may be shared among multiple
architectures.  If one runs tests *after* installing gcc, as I do, it
may get random errors for Solaris2.5 and Linux (the fastest ones)
because the SunOS4.1.3 host decided to clean up include/g++

What if the clean-include step were not mandatory, or if it just
cleaned up files older than one day, for instance?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Snapshot

[Jeffrey A Law]

  In message < orwwjedyu1.fsf@sunsite.dcc.unicamp.br >you write:
  > If include/g++ were installed in exec-prefix, or even in the
  > architecture-specific g++ directory, there would not be such problem.
I thought this had been discussed at one point.  I don't know what
ever came out of that discussion.

I used to run things like this at the UofU since we tended to
have multiple versions in use at the same time.

jeff

Re: Snapshot

[Alexandre Oliva]

Jeffrey A Law writes:

>   In message < orwwjedyu1.fsf@sunsite.dcc.unicamp.br >you write:
>> If include/g++ were installed in exec-prefix, or even in the
>> architecture-specific g++ directory, there would not be such problem.

> I thought this had been discussed at one point.  I don't know what
> ever came out of that discussion.

Probably, at that point, egcs did not even exist, and libstdc++ was
contained in an independent package.  It might not be that easy to
make sure it would be installed in the proper directory.  Now that
libstdc++ is distributed together with egcs, there's no reason for
keeping it where it is.

> I used to run things like this at the UofU since we tended to
> have multiple versions in use at the same time.

So do we at IC/Unicamp

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Snapshot

[Jeffrey A Law]

  In message < ork9fefhle.fsf@sunsite.dcc.unicamp.br >you write:
  > Joe Buck writes:
  > 
  > > OK.  Please fix "make install" to clean out $prefix/include/g++ first;
  > > otherwise users are testing a mixture of the current and previous
  > > snapshots.
  > 
  > this is a bit dangerous, since this directory may be shared among multiple
  > architectures.  If one runs tests *after* installing gcc, as I do, it
  > may get random errors for Solaris2.5 and Linux (the fastest ones)
  > because the SunOS4.1.3 host decided to clean up include/g++
Yup, it is dangerous -- Cygnus has run into problems with this kind of
stuff before.

However, we do need to find some way to address the problem of stale
files in the include installation directory.  Until we do I highly
recommend folks wipe it out before doing an install.

  > What if the clean-include step were not mandatory, or if it just
  > cleaned up files older than one day, for instance?
Well, another approach would be to issue a warning and demand user
intervention if files are found in the dir which aren't part of
the current distrubtion.  I don't know how feasible this is.

jeff

Re: Snapshot

[Alexandre Oliva]

Jeffrey A Law writes:

> Yup, it is dangerous -- Cygnus has run into problems with this kind of
> stuff before.

If include/g++ were installed in exec-prefix, or even in the
architecture-specific g++ directory, there would not be such problem.
Besides, it would allow one to have multiple versions of egcs'
libstdc++ installed, which is currently impossible, as one will
overwrite another.  With the expected include-files changes required
by the new template syntax, it might be quite annoying to have to keep
different directory trees just for the sake of preserving an old
version of g++.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: [ECGS] Snapshot

[chip]

According to Alexandre Oliva:
> What if the clean-include step were not mandatory, or if it just
> cleaned up files older than one day, for instance?

That later would be very dangerous, as it might work if you installed
other architectures today but not if you did so last Friday.
-- 
Chip Salzenberg          - a.k.a. -           <chip@pobox.com>
        "He's Mr. Big of 'Big And Tall' fame."  // MST3K

Re: Snapshot

[Jeffrey A Law]

  In message < oru3eidxe2.fsf@sunsite.dcc.unicamp.br >you write:
  > Probably, at that point, egcs did not even exist, and libstdc++ was
  > contained in an independent package.
It was quite a while ago.  I don't remember how long -- certainly
before egcs was organized.
jeff

Re: Snapshot [dealing with old versions]

[Per Bothner]

Jeff <law@cygnus.com> writes:
> However, we do need to find some way to address the problem of stale
> files in the include installation directory.  Until we do I highly
> recommend folks wipe it out before doing an install.

This is of course one of the problems a proper packaging system
takes care of.  That is keep a list of files installed by a package;
when another version of the same package is installed, then the
old version is first de-installed.

My suggestion:  Maintain a package deta-base in $exec_prefix/packages.
Each installed package (such as gcc) contains a file in that
directory specifying verious package information, plus a list of
files installed for that package, and whatever other information is
needed to unstall the package.  'make install' of gcc should check
if $exec_prefix/packages/gcc exists; if so it should first remove
the old version.  Perhaps safer:  refuse to install anything if there
is an older version, unless given some kind of "force" flag.

Note that the package database is in $exec_prefix/packages;  that
directory contains all the information about packages installed
using that --prefix.  Thus packages installed in /usr and those
installed in /usr/local would not conflict.

Note that this scheme is basically one half (third?) of a
package management system.  For best results, we should
negotiate with Debian, RedHat et al for a common package
database format (with room for extensions), and make this be
an extension of the Linux file system standard.  (Currently,
I believe Debian and RedHat can only support a single global
package database.  My suggestion would require moving that to
/usr/packages, with other package databases being used if some
other --prefix is specified.)

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner