public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Laurent Guerby <guerby@acm.org>
To: Jim Wilson <wilson@redhat.com>
Cc: Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org
Subject: Re: Installation proposal
Date: Wed, 27 Feb 2002 14:43:00 -0000	[thread overview]
Message-ID: <3C7D4DFC.8090208@acm.org> (raw)
In-Reply-To: <xwu8z9e4red.fsf@renascence.sfbay.redhat.com>

Jim Wilson wrote:

> If the install is overwriting /usr/bin/gcc, then it is a really good idea
> to test it before installing it.  I don't recommend doing builds that way,
> but some people do.

People installing a system compiler have probably their own
install and test system (like recompiling the kernel, then checking the
build of a few gigabytes of free software). We probably
look like testing amateurs to them :).

Who is seriously using configure with prefix /usr on a regular basis?

> If you are building something to install in a location that you don't have
> write access to, then you can still test it.  Otherwise, you need to su root
> first before you can test it.

If our accepted target is location independance, then this argument is void.

My own user policy is all root stuff is installed through binary
packaging systems, everything else is installed with user
permission (other solution I used where far worse :).

The ACT GNAT install process is location independant
and it does so by having a 10 line wrapper script that sets the needed 
env var and
then call the real bin for all of its tools (using $0).

> It makes the code-test-debug cycle faster, if you don't have to do an install
> after writing code and before testing it.  

Full C+Ada install is 65s on my machine (boot is 47 minutes, check is 28 
minutes,
ACATS is 32 minutes). Doesn't look like a real argument. Plus as far as 
I can
judge people code-test-debug on one test file (the bug) by using
gdb on xx1, they don't run the full test suite after each one line change,
they run it once it works reasonably on their test case, then bootstrap
+ check is going to take a while but install time is irrelevant then.

 > It also saves on disk space during the development cycle.

With C+Ada install takes less space than a stage, and about 25%
of a full make boostrap. If you are this short on space, then
I don't even see how you can do any development work.

> But yes, when you get to the point where you are making a release, it is
> mandatory to test the installed compiler.  

And release are where we should be good on testing (easy to automate,
testing what user will see). Why not use the same thing while developing?
If we don't then all the trouble is for our loved release manager at
release time :).

> The current testsuites can be used
> to test an installed compiler if there is no compiler in the build tree.

Is this documented? (I remember only seeing "make -k check").
I would be *really* interested.

-- 
Laurent Guerby <guerby@acm.org>

  reply	other threads:[~2002-02-27 21:22 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-27 10:11 Mark Mitchell
2002-02-27 10:25 ` H . J . Lu
2002-02-27 10:26 ` David Edelsohn
2002-02-27 10:59   ` Jim Wilson
2002-02-27 13:05   ` Michael Meissner
2002-02-27 10:50 ` Paul Koning
2002-02-27 11:02 ` Stan Shebs
2002-02-27 11:04 ` Joseph S. Myers
2002-02-27 11:25   ` Mark Mitchell
2002-02-27 12:10     ` Joseph S. Myers
2002-02-27 11:05 ` Joel Sherrill
2002-02-27 11:53   ` Joseph S. Myers
2002-02-27 11:07 ` Tom Tromey
2002-02-27 11:26   ` Mark Mitchell
2002-02-27 14:55   ` Richard Henderson
2002-02-27 17:38     ` Alexandre Oliva
2002-02-27 17:45       ` Richard Henderson
2002-02-27 18:27         ` Alexandre Oliva
2002-02-28  0:04           ` Richard Henderson
2002-02-28  2:02       ` Joseph S. Myers
2002-02-28  2:25         ` Alexandre Oliva
2002-02-27 11:13 ` Laurent Guerby
2002-02-27 12:11   ` Zack Weinberg
2002-02-27 12:17   ` Jim Wilson
2002-02-27 14:43     ` Laurent Guerby [this message]
2002-02-27 12:52   ` Neil Booth
2002-02-27 11:18 ` Jim Wilson
2002-02-27 14:56   ` Daniel Jacobowitz
2002-02-27 17:18   ` Mark Mitchell
2002-02-27 17:20     ` Richard Henderson
2002-02-27 17:59       ` Mark Mitchell
     [not found]       ` <mailpost.1014859095.10690@news-sj1-1>
2002-02-27 18:16         ` cgd
2002-02-27 11:23 ` Per Bothner
2002-02-28  1:39   ` Akim Demaille
2002-02-27 14:56 ` Nathan Sidwell
2002-02-27 16:11 ` Loren James Rittle
2002-02-27 17:47 ` Alexandre Oliva
2002-02-27 18:00   ` Daniel Jacobowitz
2002-02-28 14:06     ` Alexandre Oliva
2002-02-27 18:33   ` Mark Mitchell
2002-02-28  9:18     ` Per Bothner
2002-02-28  9:42       ` Mark Mitchell
2002-02-28  1:13   ` Akim Demaille
2002-02-27 10:48 Mark Mitchell
2002-02-27 11:07 Benjamin Kosnik
2002-02-27 13:22 mike stump
2002-02-28 11:51 mike stump
2002-02-28 12:56 ` Mark Mitchell
2002-02-28 14:04 ` Alexandre Oliva
2002-02-28 14:28   ` Per Bothner
2002-02-28 16:32   ` Richard Henderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C7D4DFC.8090208@acm.org \
    --to=guerby@acm.org \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    --cc=wilson@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).