Date:	Thu, 14 Dec 2000 11:30:44 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Peter J. Farley III" <pjfarley AT banet DOT net>
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:	<Pine.SUN.3.91.1001214113012.25353A-100000@is>
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

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

- Raw text -