Message-Id:	<4.3.1.0.20001106183035.00aba290@pop5.banet.net>
X-Sender:	usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer:	QUALCOMM Windows Eudora Version 4.3.1
Date:	Mon, 06 Nov 2000 18:35:28 -0500
To:	djgpp-workers AT delorie DOT com
From:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Subject:	Re: How do I build an isolated test version with new fcntl?
Cc:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
In-Reply-To:	<Pine.SUN.3.91.1001106091102.9527B-100000@is>
References:	<4 DOT 3 DOT 1 DOT 0 DOT 20001105124326 DOT 00ade980 AT pop5 DOT banet DOT net>
Mime-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

At 09:12 AM 11/6/00 +0200, Eli Zaretskii wrote:
<Snipped>
 >Making a separate "make install" target is not easy, since one of the
 >goals of the build process is to be able to run on a bare-bones DOS
 >system with a working djdev/GCC/Binutils/Make installation as the 
only
 >prerequisites.  (To say nothing of the fact that no one has yet made
 >the test suite work in an automated fashion, you must run each test 
by
 >hand.)
 >
 >Add to this that the build must also run in a cross-compiled
 >environment on a Unix box, and you will see why it doesn't follow the
 >build/test/install paradigm.  If someone wants to work on making it
 >more compatible, please do.

Understood.  And thanks for the explanation.

 >> Do I have to set up a parallel DJGPP installation that I'm not
 >> afraid to trash with bad builds?
 >
 >Yes, you need a separate tree.  You don't need to copy all of the
 >DJGPP installation to that tree, only unzip djdev203.zip and
 >djlsr203.zip in some place that is NOT your production DJGPP tree.
 >
 >The library build process builds the entire djdev tree whose location
 >is relative to the src directory where you run Make.  That is, the
 >binaries go to ../bin, libraries to ../lib, Info files to ../info,
 >etc.  The build process uses special GCC switches to make sure the
 >compilation and link use headers and libraries from ../include and
 >.../lib, respectively, so it doesn't depend on the files from the
 >production version.

OK, thanks for the specific instructions.

 >Once you think you have a working fcntl/flock, and want to start
 >building applications with it, update your production tree with the
 >modified headers and library functions (ar rvs libc.a fcntl.o), and
 >work as usual from your production DJGPP tree.

Sounds like a plan to me.

 >> At this point, since I *think* I also saw gcc's djgpp.djl being
 >>rebuilt along the way, I'm concerned that I have to re-install 
gcc->>2.952 as well.
 >
 >The build process doesn't rebuild djgpp.djl (how can it? it's a
 >human-generated file), it just uses it explicitly on the command line
 >when it links programs; that is what you saw.  And since GCC doesn't
 >come with djgpp.djl, you don't have to worry about the GCC
 >installation.

Thank you again for easing my mind on that.

 >> I have (I hope) restored my installation by unzipping
 >> djdev203.zip and overwriting everything, and then restoring my
 >> DJGPP.ENV from a saved copy.
 >
 >DJGPP.ENV is also not touched by the library build, you could have
 >left it alone.

No harm done, though I'll remember that the next time.

 >> Is there anything else built by "make" in /src that I need to worry
 >> about restoring?
 >
 >It doesn't touch anything except things that come with djdev and 
djtzn
 >(the latter only if you have djtzs unpacked).  But if you want to be
 >absolutely sure, run "ls -lgtr %DJDIR%/.../*" and look at the files
 >near the end which were created at the time of your "make" run in the
 >src directory.

I'll do that.  Back to work... ;)
---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -