Re: Questions about the CVS build process

[Tkil <tkil at scrye dot com>]

>>>>> "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