discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Totally Gormless


From: Armando Di Cianno
Subject: Re: Totally Gormless
Date: Wed, 12 Oct 2005 09:06:57 -0400

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2005-10-12 03:21:51 -0400 Richard Frith-Macdonald
<richard@brainstorm.co.uk> wrote:
I'm not sure about removing user_home.c ... it might be more complex to handle it in shell scripts than in a C program... we have two files to parse .... the system-wide config file and the per-user file. We need to parse the system-wide file to determine the location of the per-user file (which we could do by sourcing it), but we can't just source the per-user file, unless we want to accept it overriding values from the system-wide file. If we *do* want to allow the per-user file to override the system-wide file, we would have to implement that in NSPathUtilities too. I guess we could use sed to extract the required values from the second file .... depends whether we want this process to be as fast as possible, or are willing to tolerate runnign a coule of sed child processes ... I'm not really bothered by the overhead.

Hrm.  Okay, here's a couple of ideas:

0) Move gnustep-make into gnustep-base.
I like this, but it's probably bad because some other projects depend
solely on gnustep-make.

1) Make gnustep-make install GNUstep.conf, and have user_home work as
NSPathUtilities.m does.
I like the idea of this, but NSPathUtilities.m is quite complex, and I
hate the idea of repeating code.  Although, if this is done for the
next release, maybe we can start to not support the old GNUsteprc
stuff, which would make this easier.

2) Move user_home into gnustep-base.
We could probably even call it "ns_path_utility" or something like
that; it could of course link straight to the NSPathUtilities.m code,
so no code has to be repeated.  Considering I feel NSPathUtilities.m
is a bit complex, I really like this idea, since the code doesn't have
to be repeated.  The only real breakage that should/could ensure in
gnustep-make, is that gnustep-make doc's would still have to build;
i.e. they would have to build w/o sourcing GNUstep.sh.  Also, the
user_home/ns_path_utility program could be locked to the System
Domain, so user's couldn't override it with their own.  Maybe it would
just be a Tool then, but locked to System.

Thoughts?  I'd be happy to crank out any of these ideas soon.  I think
a combination of 1 and 2 would be great -- make gnustep-make install
GNUstep.conf, and have gnustep-base provide the user_home utility.

__Armando Di Cianno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1-ecc0.1.6 (GNU/Linux)
Comment: Using the GPG bundle for GNUMail

iD8DBQFDTQpxwgiTPLI9xhcRAnz1AKCy2PTFkOv431IicTnpszrVyab2iwCaAt7/
LN+/Y2l/W++RMY2TW2sLrf4=
=FPH7
-----END PGP SIGNATURE-----





reply via email to

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