discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Totally Gormless


From: Nicola Pero
Subject: Re: Totally Gormless
Date: Tue, 11 Oct 2005 20:59:50 +0100 (BST)

> > Ahm ... we have a check that ObjC "really" works in gnustep-base's
> > configure step ... presumably your point is that you think that that check
> > should rather be done in gnustep-make ?
> 
> Well ... yes and no.  Sane use of CFLAGS should definitely be up to
> either the person compiling by hand, or the package maintainer in a
> distro.  Also, ideally, I don't think that gnustep-make should compile
> anything at all, but rather by easily relocatable; everything being
> based on the env. settings of GNUSTEP_MAKEFILES (only for
> dev/building) and GNUSTEP_SYSTEM_ROOT.

I'm not sure I get what you're trying to say.

You seem to imply that having the two C command line tools in gnustep-make 
breaks relocatability.  Can you explain your argument more in detail ?

Thanks


> > Not sure why you want to remove the C code from gnustep-make though, given
> > that implementing user_home or which_lib using a scripting language is too
> > slow; and C is the most widely portable and optimized compiled language
> > available. ;-)
> 
> There's two main reasons:
> - - Currently, user_home is broken; it doesn't pay attention to
> GNUstep.conf

Well, let's fix it! :-)

Patches welcome.


> - - it is only called *once* from GNUstep.sh (currently)
>
> [...]
>
> ... so it takes about 2 times as long to run -- which still amounts to
> a split second. ;-)

PS: That's a lot slower ;-)

... but looking at your code, I'm certainly not opposed to replacing
user_home with a sed one-liner if we know that the sed one-liner will
always work properly (eg, on all platforms) [and I believe I can optimize
the sed stuff so it goes as fast, if not faster, than user_home.c]. ;-)

The reason we have user_home.c is that the code to determine the user home
wasn't exactly simple, and couldn't be done properly with a single unix 
command ...

... if that's the case now -- and if it can be done simply and
consistently on all platforms that way -- then why not. ;-)

PS: My original idea was to simply include GNUstep.conf in shell scripts.  
I hope the idea has been kept in the sense that the GNUstep.conf syntax is
compatible with sh syntax.  If so, and if we can just include GNUstep.conf
in shell scripts (and makefiles!) instead of running C tools, that would
be as fast and simple as you can get it. :-)

I seem to remember there is lot of hidden complexity in here, but don't
remember much about the details, so probably reading old email archives 
and checking what the code does etc. is required! ;-)


> Honestly, I think a gnustep-make package that was just a bundle of build
> files would be much more powerful than the one that gets compiled / has
> GNUstep.sh / etc.

I doubt compiling which_lib.c and user_home.c has much impact on this, but
we certainly all agree about getting rid (or reducing) the need for
GNUstep.sh ;-)



> I also have patches for gnustep-base, that are path related.  For
> example, $HOME is ignored in the code that figures out where the
> Defaults Library gets written, so for e.g., I can specifiy the home
> for gdomap to not be "/root", which is ridiculous, imho. My main goal
> is to make them integrate nicely with the current GNUstep.conf based
> way, rather than make something entirely new, that'll likely be
> rejected. :-)

Well I'm not sure about that but you should certainly submit your patches
... why keeping them hidden ... ;-)

Thanks





reply via email to

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