Questions about the CVS build process

Questions about the CVS build process

[Tkil]

Hi there.  I am building from the CVS sources (as of about 2000-11-14
20:00 -0700), and I have a few questions:

1. Can a snapshot be converted into a CVS sandbox?  I ended up just
   doing a full cvs checkout, but at least one other large project
   (mozilla) recommends downloading the snapshot, unpacking it, then
   using cvs to grab only the deltas since then.  (They apparently
   simply package up the CVS subdirectories in the snapshot tar file,
   and it "just works."  I'm no CVS guru, so I'm probably missing
   something obvious).

2. Can the install prefix be changed after doing a bootstrap?  Or do I 
    have to do a full configure + bootstrap cycle again?

3. Is there a way that configure can detect that it's being run in the
   source directory (instead of a sibling "build" directory of some
   sort), and abort?  I didn't read the instructions closely enough
   the first time, and apparently I did enough damage to the sources
   that it was quite unhappy.  I ended up removing the first tree and
   doing another checkout from scratch, and it seemed much happier
   after that.

   (In case anyone cares, it died looking for "../install-sh" or
   similar.  I just blew away that portion of the build log, of
   course, otherwise I'd have the actual error for you...)

If these questions are answered in the docs, then I apologize for the
inconvenience, and a pointer would be appreciated.

Thanks,
Tony

p.s. Should I/we care about the fairly large number of these warnings?

     warning: integer constant is unsigned in ANSI C, signed with -traditional
     warning: comparison between signed and unsigned

Re: Questions about the CVS build process

[Eric Christopher]

> 1. Can a snapshot be converted into a CVS sandbox?  I ended up just
>    doing a full cvs checkout, but at least one other large project
>    (mozilla) recommends downloading the snapshot, unpacking it, then
>    using cvs to grab only the deltas since then.  (They apparently
>    simply package up the CVS subdirectories in the snapshot tar file,
>    and it "just works."  I'm no CVS guru, so I'm probably missing
>    something obvious).

Probably.  I see no advantage to it though, you have to download the
same amount of stuff ultimately.

> 
> 2. Can the install prefix be changed after doing a bootstrap?  Or do I
>     have to do a full configure + bootstrap cycle again?

You can reconfigure in the build directory and rebuild - it _should_
only rebuild stuff that's necessary, but I haven't tried this with a
bootstrap.  Alternately you could tar everything up and move it, it
should work fine.

> 
> 3. Is there a way that configure can detect that it's being run in the
>    source directory (instead of a sibling "build" directory of some
>    sort), and abort?  I didn't read the instructions closely enough
>    the first time, and apparently I did enough damage to the sources
>    that it was quite unhappy.  I ended up removing the first tree and
>    doing another checkout from scratch, and it seemed much happier
>    after that.
> 

Probably could find a way to check it - I'm not sure if this would be
acceptable or a good idea though. Anyone have a comment?

> p.s. Should I/we care about the fairly large number of these warnings?
> 
>      warning: integer constant is unsigned in ANSI C, signed with -traditional
>      warning: comparison between signed and unsigned

Well, yes and no.  Yes, we should care about them, but don't worry about
it right now ;)

-eric

Re: Questions about the CVS build process

[Tom Tromey]

>> 3. Is there a way that configure can detect that it's being run in
>> the source directory (instead of a sibling "build" directory of
>> some sort), and abort?

Eric> Probably could find a way to check it - I'm not sure if this
Eric> would be acceptable or a good idea though. Anyone have a
Eric> comment?

I thought building in the source directory was supported.

If not, I have a trivial patch to the toplevel configure which detects
this scenario and aborts.  We use it for libgcj.

Tom

Re: Questions about the CVS build process

[Joern Rennecke]

> 
> > 1. Can a snapshot be converted into a CVS sandbox?  I ended up just
> >    doing a full cvs checkout, but at least one other large project
> >    (mozilla) recommends downloading the snapshot, unpacking it, then
> >    using cvs to grab only the deltas since then.  (They apparently
> >    simply package up the CVS subdirectories in the snapshot tar file,
> >    and it "just works."  I'm no CVS guru, so I'm probably missing
> >    something obvious).
> 
> Probably.  I see no advantage to it though, you have to download the
> same amount of stuff ultimately.

It won't work curently, because the snapshots don't include the CVS
directories with all the bits and pieces.
And if they did, the Root files there would specify the access method.
So we'd have to standarize on one cvs access method that would be
supported by the snapshots.

There are shell scripts to switch the root and access method, though.

An obvious advantage is that it's easier to mirror snapshots, so you'd
have a wider choice of sites from where to download the bulk of the
stuff you need.  This could help developers in less-well-connected part
of the net.

Re: Questions about the CVS build process

[Philip Blundell]

>> 1. Can a snapshot be converted into a CVS sandbox?  I ended up just
>>    doing a full cvs checkout, but at least one other large project
>>    (mozilla) recommends downloading the snapshot, unpacking it, then
>>    using cvs to grab only the deltas since then.  (They apparently
>>    simply package up the CVS subdirectories in the snapshot tar file,
>>    and it "just works."  I'm no CVS guru, so I'm probably missing
>>    something obvious).
>
>Probably.  I see no advantage to it though, you have to download the
>same amount of stuff ultimately.

According to the mozilla.org folks, it's considerably faster to download the 
bulk of the data by ftp than to let CVS check it all out.  (Given the 
usually-overloaded state of the sourceware machine I can well imagine this 
would be true for GCC.)

p.

Re: Questions about the CVS build process

[Tkil]

>>>>> "Tkil" == Tkil  <tkil@scrye.com> writes:

Tkil> 1. Can a snapshot be converted into a CVS sandbox?  I ended up
Tkil>    just doing a full cvs checkout, but at least one other large
Tkil>    project (mozilla) recommends downloading the snapshot,
Tkil>    unpacking it, then using cvs to grab only the deltas since
Tkil>    then.  (They apparently simply package up the CVS
Tkil>    subdirectories in the snapshot tar file, and it "just works."
Tkil>    I'm no CVS guru, so I'm probably missing something obvious).

>>>>> "Eric" == Eric Christopher <echristo@cygnus.com> writes:

Eric> Probably.  I see no advantage to it though, you have to download
Eric> the same amount of stuff ultimately.

>>>>> "Philip" == Philip Blundell <philb@gnu.org> writes:

Philip> According to the mozilla.org folks, it's considerably faster
Philip> to download the bulk of the data by ftp than to let CVS check
Philip> it all out.  (Given the usually-overloaded state of the
Philip> sourceware machine I can well imagine this would be true for
Philip> GCC.)

Well, you should always get better compression by aggregating first
(as in a tar file) and then compressing it, compared to compressing
each file individually.  I don't know how CVS does its compression, so 
I don't know how much this impacts a "-z" cvs update, but it's
something to consider.  (In the frightening world of gcc, where we
have single source files that are large fractions of a megabyte in
size, this argument is perhaps not as persuasive.  :)

If nothing else, the snapshot only needs to be compressed once,
instead of every time someone checks out the tree.  How often people
do full checkouts of a tree from scratch, I don't know.

Anyway, the real reason I'm writing is that did another build with
obj-dir set to src-dir.  I got the same error:

| $ ./configure --enable-libstdcxx-v3 --prefix=/usr/local/gcc-2.97-2
| Configuring for a i586-pc-linux-gnu host.
| Created "Makefile" in /usr/local/src/gcc/gcc2 using "mt-frag"
| [ ... 6778 lines later ... ]
| checking whether to enable maintainer-specific portions of Makefiles... no
| configure: error: can not find install-sh or install.sh in .. ./..
| make[1]: Leaving directory `/usr/local/src/gcc/gcc2'
| $ 

More details on my system (Red Hat 6.2 + some errata) are available if
you want them.  I have placed the build log online at:

   http://slinky.scrye.com/~tkil/gcc/build-in-src-dir.txt.gz

(~630kB uncompressed, ~60kB gzipped)

These sources were updated at about 11a local time, which translates
into 2000-11-15 18:00 GMT (or so).

>>>>> "Tom" == Tom Tromey <tromey@cygnus.com> writes:

Tom> I thought building in the source directory was supported.

I remembered (probably towards the end of the build :) reading that a
separate build directory was strongly suggested, but yes, i thought it
was still "supported".  The current docs indicate:

| First, we *highly* recommend that GCC be built into a separate
| directory than the sources which does *not* reside within the source
| tree.  This is how we generally build GCC; building where "srcdir"
| == "objdir" should still work, but doesn't get extensive testing;
| building where "objdir" is a subdirectory of "srcdir" is
| unsupported.

[from wwwdocs/install/configure.html]

But, as someone else pointed out in private correspondence, the
"usual" technique for autoconf'ed packages is to unpack it, go into
the main directory, "./configure" and build there.  I certainly got
lulled into it, and while I blame only myself, it's something to
consider.  (Then again, if people are building GCC, one might presume
that they are a few notches above a blind download/unpack/config/
build/install process...)

Tom> If not, I have a trivial patch to the toplevel configure which
Tom> detects this scenario and aborts.  We use it for libgcj.

Well, waiting an hour and having it die is an unhappy thing.  I'd
personally prefer to see it fixed so that it works, The trivial patch
might be a good temporary fix to avoid disappointment for people whose
boxes are even slower than mine (full bootstrap, ~85 minutes).

Thanks for your time.  If I can do any more investigation on this,
please let me know.

Tony

Re: Questions about the CVS build process

[Tom Tromey]

Tkil> I don't know how CVS does its compression, so I don't know how
Tkil> much this impacts a "-z" cvs update, but it's something to
Tkil> consider.

FYI, cvs compresses the entire data stream.

The real issue is that of mirrors: if the snapshots had the CVS
directories in them then this could help lessen the network load on
gcc.gnu.org.

Tom

Re: Questions about the CVS build process

[Gerald Pfeifer]

On 15 Nov 2000, Tom Tromey wrote:
> I thought building in the source directory was supported.

I is (should be) to the very best of my knowlege. It is not what we
recommend in the installation instructions, but it should work.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/