> > 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 _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
