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" Subject: Re: How do I build an isolated test version with new fcntl? Cc: Eli Zaretskii In-Reply-To: References: <4 DOT 3 DOT 1 DOT 0 DOT 20001105124326 DOT 00ade980 AT pop5 DOT banet DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Precedence: bulk At 09:12 AM 11/6/00 +0200, Eli Zaretskii wrote: >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)