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 From: "Peter J. Farley III" Subject: Re: Locking fcntl changes #2 Cc: djgpp-workers AT delorie DOT com In-Reply-To: References: <5 DOT 0 DOT 2 DOT 1 DOT 0 DOT 20001212202501 DOT 025a4b30 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 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)