Message-Id:	<5.0.2.1.0.20001213200056.025c20f0@pop5.banet.net>
X-Sender:	usbanet DOT farley3 AT pop5 DOT banet DOT net
X-Mailer:	QUALCOMM Windows Eudora Version 5.0.2
Date:	Wed, 13 Dec 2000 20:22:22 -0500
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
From:	"Peter J. Farley III" <pjfarley AT banet DOT net>
Subject:	Re: Locking fcntl changes #2
Cc:	djgpp-workers AT delorie DOT com
In-Reply-To:	<Pine.SUN.3.91.1001213131835.11254D@is>
References:	<5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001212202501 DOT 025a4b30 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 01:19 PM 12/13/00 +0200, Eli Zaretskii wrote:
 >
 >On Tue, 12 Dec 2000, Peter J. Farley III wrote:
 >
 >> Yes, I can see now that it would be better to break it up a
 >> little.  After I fix all the things Eli  has pointed out, I will 
put
 >> together a script to make some kind of logical separation into
 >> multiple packages.
 >
 >You could simply use your favorite text editor to make several files
 >from a single one...

Yes, but I'd rather apply a small amount of intelligence to the 
split-up process, so that only things that *need* to be together are in 
the same file.  E.g., I might split out all of the documentation 
updates in /src together.  It shouldn't be too hard.

 >> But in any case, all of the
 >> diff packages will have to be applied together for all the changes
 >> I've made to build and test correctly.
 >
 >That's not very good: it means that the patches aren't independent.
 >
 >But I don't see why all of them need to be applied at once.  For
 >example, if I'm not rebuilding dbgcom.c, I don't need to patch it,
 >right?  And the same is true for _dosexterr: unless someone wants to
 >build and run the tests for the new fcntl, they don't need 
_dosexterr,
 >since only the test programs call it, right?

To that last, true.  However, what's the point of building a library 
without also building the tools needed to test the changes?  (dbgcom.c 
is an exception, it's not needed by anything I've done.)

I have just been making all of /src at the same time.  I could package 
just the things needed to do make when in /src/libc together, and 
separate out the other changes, but I don't know if that would reduce 
the size by much.

I would not want the crt0 or exceptn changes left out, though, since 
I'm not sure anything would work without them.  I think I will do as I 
said above, and perhaps make three files out of it:

/src/libc code changes
/src/libc/ doc changes
All other /src changes

That first one will still not be small, and it will require the 
/include changes to build correctly.  I may still have to split the 
first one into two arbitrary pieces of about the same size.

OTOH, it should also be possible to divert the _dosexterr/_dostrerr 
changes out of the first file and into the third one, to save more 
space.  _dostrerr in particular is quite large, so that should help 
with the size issue.

Dependency-wise, the first package described above would have to be 
applied along with the /include changes to get a successful 
build.  Then the third package and the /test package would have to be 
applied and libc would have to be rebuilt again (to get _dostrerr) in 
order to test the library.  The doc package could be applied 
separately.

Does that sound at all logical or practical?

---------------------------------------------------------
Peter J. Farley III (pjfarley AT dorsai DOT org OR
                      pjfarley AT banet DOT net)

- Raw text -