discuss-gnustep
[Top][All Lists]
Advanced

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

Re: GNUstep.sh / env sanity patches


From: Armando Di Cianno
Subject: Re: GNUstep.sh / env sanity patches
Date: Fri, 13 Aug 2004 09:57:57 -0400

On 2004-08-12 23:22:04 -0400 Sheldon Gill <sheldon@westnet.net.au> wrote:
Considering the patches were posted on Tuesday and it is only Friday now I'd say patience is a virtue. It takes time to review patches and some of us have RL to deal with. I think it's reasonable to wait at least until a weekend has gone by before getting impatient.

Right on. I sort of wanted to trigger discussion about it, which has happened, more so than demand its immediate overview or anything like that. Patience is definitely a virtue.

One thing is that it contains big changes to configure, not configure.ac so they'll be lost at the next autoconf...

I believe I included all neccessary configure.ac changes (checking on that), and i wasn't sure whether to include the configure diffs in the patch. Other changes when into GNUmakefile.in. I blame the differences generated in configure likely from different versions of autoconf or something like that; I really didn't know whether to include it or not ... really, "./configure" isn't supposed to be included in source packages anyway, is it? Kind of something that just stuck around 'cause it's pretty silly to auto generate it all the time, right?

Another big thing is the incorrect memory handling w.r.t. environment variables.

How so?  I can fix this if you tell me what was done incorrectly. :-)

So basically I'd definitely reject make- and base- because of the bugs and because of architecture changes.

The bugs hopefully can be fixed if I figure out what's wrong, but ... well, yeah, it is an architecture change, but I was focusing on not changing old behavior: I just need things to _work_ at this point. I mean, the point was a very light, fully backwards compatible architecture change, so if it's rejected because of an architecture change ... well, I wouldn't know what to say, as that's the point.

The stepsh-env patch is going to take more digesting.

The patch is (embarrassingly?) simple: one of the scripts only sets the env, the other calls make_services and looks for a ~/GNUstep/GNUstep.sh (same as the old GNUstep.sh did) .... the new GNUstep.sh calls both, for compatability with the old GNUstep.sh.

I'd like to see GNUstep.sh killed because it doesn't work in my shell. I don't know what's happening with this, though. When I asked #gnustep,
"lack of developer time" was thought to be the hold-up.

I've got GNUstep.sh killed for users but not for developers. gnustep-make is too heavily dependent on it at the moment to make it immediately disappear.

Oh, this I would love to help test ... hasn't killing it for users been the only goal? I suppose developers are uses too. :-) heh.

__armando

P.S. Just to be clear, I hope I'm not coming off as "pissy" or "angry" or anything like that. I, like you, really want to fix this "the right way", but this patch, I was hoping, was a good short term extension, for my ends, that didn't screw anyone else up. When you do go over it, please let me know the better/correct way to handle memory in this case -- it can only serve both our ends for you to elucidate my mistake ... betters the moral/coding ecology or something like that. ;-) So, I guess, please just realize that while the problems I'm having are very frustrating to me, I'm not trying to push it's resolution as a priority on anyone else. I'd rather people in our realm see me as a teammate and not some interloper.

P.P.S. I hate string/memory handling in straight C. ;-)





reply via email to

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