[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSPathUtilities Patch - TOC

From: David Ayers
Subject: Re: NSPathUtilities Patch - TOC
Date: Wed, 21 Apr 2004 12:22:12 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

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

- 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]