Re: NSPathUtilities Patch - TOC

[David Ayers]

Sheldon Gill wrote:

> On Tue, 20 Apr 2004 17:12, David Ayers wrote:
>
>
> > Hmm, I was hoping the patches would match the ChangeLogs.  But if this
> > is the "combined" ChangeLog then Source/GNUmakefile seems to be missing.
>
>
> Yes this is the "combined" ChangeLog, I'm afraid.  There didn't seem to be 
> much point in separating it out:

That's unfortunate, I must admit I was a bit quick about the praise as I
do agree with Fred.  I was mislead the mail subjects lines and smaller
patches, not realizing yet that the patches aren't coherent but a large
patch simply split by files.

> The Win32 additions are only called by NSPathUtilities.m so patching them in 
> separately only tests clean compilation and doesn't exercise the code at all.
> The NSUser patch stand alone would break compilation as it removes things to 
> pave the way for NSPathUtilties.m
> The NSUserDefaults patch is required because the behaviour of 
> GSDefaultsRootPath() changes somewhat.
> The NSBundle patch depends on GSFindNamedFile() which is in NSPathUtilities.m
> and could be considered a separate patch with a clean dependency.

I don't understand why it's so hard to split the issues into separate
patches.  There is also no requirement that the all need to sent at the
same time.  Could you /pretty/ please check out a new -base tree, apply
one issue at a time, test it, post a patch, potentially revise and
commit upon approval and then apply the next issue to that tree.

From looking at the patch I think this may be a good sequence:

- NSUserDefaults patch which doesn't seem to depend on anything else.
I'm sure there are still issues like that define that I'm personally not
to fond of (but I don't want to discuss in this thread).

- "move" NSUser.m to NSPathUtilities.m which I think was not
controversial but retain the NSUser.m contents.  This patch would
include the Makefile changes necessary to stop building the NSUser.m a
build NSPathUtilities.m

- add the NSPathUtilities patches that cleanup the code w/o changing the
behavior.

- add GNUstep.conf support.

- add the Win32 support.
(I'm not sure if the last two need to be inverted or not.)

- change current behavior wrt NSPathUtilities functions.

- resolve NSTemporaryDirectory issue.

- Add testing.  (Well these can be added as soon as it makes sense but 
in a separate patch.)

Yes you'd have intermediate version of NSPathUtilities.m but I also
think it's important to have the evolution in CVS.  Especially to
determine what change (as it might be conceptual) may break certain
features (like sourcing GNUstep-reset.sh/GNUstep.sh to get a new GNUstep
environment) so they can be addressed (like symlinking /etc/GNUstep.conf
to a a different file maybe?)

Is that viable?

Cheers,
David