Date: Thu, 14 Dec 2000 11:30:44 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Peter J. Farley III" cc: djgpp-workers AT delorie DOT com Subject: Re: Locking fcntl changes #2 In-Reply-To: <5.0.2.1.0.20001213200056.025c20f0@pop5.banet.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 13 Dec 2000, Peter J. Farley III wrote: > >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. Patches for the docs should be sent and applied together with the source patches to which they are pertinent. > >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.) dbgcom.c is not an exception: the same applies to crt0.S and exceptn.S: we don't need those changes to either build _or_ test your fcntl changes. (You might need them locally in order to build the library in the first place, because of the GCC version you are using, but they have nothing to do with fcntl's code.) We also don't need lockf to use fcntl. > I have just been making all of /src at the same time. This is indeed what you should do. But generating the diffs is another matter: you could invoke `diff' only on those files which are relevant to a specific feature. Doing a "diff -r" is of course easier, but it makes things harder on our end. > 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 No, please keep the related changes together, even if they are in .txh files or in wc204.txi, or in the include directory. Separate the diffs by the feature, not by directories or file extensions. > That first one will still not be small, and it will require the > /include changes to build correctly. Making the diffs small is not the main reason for splitting. The main reason is that we want to be able to review each feature separately, and be able to apply it separately, or even decide not to apply some of them, if we have a good reason. > 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? I'd suggest the following partition: - fcntl changes, inclduing tests, docs and header files - flock, lockf and llockf changes, inclduing tests, docs and header files - _dosexterr changes, inclduing tests, docs and header files - crt0.S, exceptn.S, and dbgcom.c changes, including changes in makefile's