Re: Totally Gormless

[Armando Di Cianno]

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

On 2005-10-11 12:45:01 -0400 Nicola Pero
<nicola.pero@operatelecom.com> wrote:
> > IIRC, this is covered by the OPTFLAGS variable in the GNUstep
> > Makefiles.  The problem comes from the fact that OPTFLAGS is not
> > necessarily equal to CFLAGS.  If gnustep-make is compiled with
> > CFLAGS="-Os -fomit-frame-pointer" (as the previous example), but then
> > one discovers that -fomit-frame-pointer is breaking something (as it
> > does with seemingly random objc related code, not to mention ffcall),
> > one should be able to simply set CFLAGS="-Os", and not have to worry
> > about other CFLAGS coming in from seemingly nowhere.
> Hmmm ... OK, so your problem is that you want to be able to specify 
> different 
> CFLAGS for compiling gnustep-make and for stuff that is compiled 
> using 
> gnustep-make ?
> Now I see your point.  :-)
> What about if we then had
> cd core/make
> ../configure CFLAGS=xxx
> make CFLAGS=yyy
> where 'xxx' would then be used whenever compiling anything using
> gnustep-make, and 'yyy' would be used when compiling the few C tools 
> in
> gnustep-make itself.
> Would that be more helpful ?

I suppose the problem is more of the de-facto policy that specifying
OPTFLAG in that location causes.  Developers should definitely be able
to change those settings in something they are building, so I'm not
saying "remove OPTFLAG"; rather, I'm saying that gnustep-make should
install with "happy defaults", which is not the case since
gnustep-make will successfully compile with options that are
detrimental to objc code (since gnustep-make has no objc files).  I
can easily filter this line out, as far as my packaging of Gentoo
ebuilds go.  But when I say:
# CFLAGS="-O1 -g" make all
I expect the only optimizations to be "-O1 -g".  What would seem a
helpful step by using what is in gnustep-make's environment when it is
built, I agree, in fact violates this.

> I think that some people are compiling by hand on platforms with
> tricky/tweaky configurations where they'd need to run an "export
> CFLAGS=xxx" everytime they compile anything.  Understandly they 
> prefer a
> default to be set in config.make ... which is what ./configure 
> CFLAGS=xxx
> is supposed to do.

Ahh, this I can understand -- I would definitely get annoyed if I
couldn't specify the OPTFLAG's once, in this scenario.

> > > Any special sort of granularity you need that is not covered by 
> > > this ?
> >
> > It's just that gnustep-make can successfully be compiled with CFLAGS
> > that *will break* objc code ... so I think it's a configuration 
> > option
> > best specific via the environment, and not an option file.
>
> 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.

> > On an unrelated note, I've been working on removing the C code from
> > gnustep-make, as well as making it generally relocatable.  You "own" 
> > /
> > maintain the gnustep-make package, correct?  If so, would you be up
> > for some review of this?  I would find it extremely helpful -- the
> > GNUstep build system was the #1 problem with installation on Gentoo
> > (via portage); there are also some minor, but gravely annoying bugs 
> > in
> > the most recent releases like "user_home helper program gives
> > different results than gnustep-base" (which I've fixes for).
>
> Thanks ... we certainly like fixes and patches ... just post them :-)
>
> 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
- - it is only called *once* from GNUstep.sh (currently)

### Current code: ./configure --with-user-root='~' and GNUstep.conf
set up appropriately ###
$ ./GS0/System/Library/Makefiles/user_home user
/home/test/GNUstep
^^^ INCORRECT!^^^

Also, considering it's called once, it's not really significantly
slower:

### Current C Code ###
$ time . ./GS0/System/Library/Makefiles/GNUstep.sh
real    0m0.089s
user    0m0.037s
sys     0m0.028s

### Icky use of sed ###
$ time . /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
real    0m0.145s
user    0m0.082s
sys     0m0.057s

... so it takes about 2 times as long to run -- which still amounts to
a split second. ;-)

Here is my current code for GNUstep.sh, but be aware, it's
non-optimized and has gratuitous use of sed:
(also note the /etc/GNUstep/GNUstep.conf -- I enforce this simply for
package/distro contraints, no biggie there; also, $HOME can be
switched with ~ ... it's just that $HOME is better supported between
shells, imho)
- -------------------
old_IFS=$IFS
IFS=$'\n'
[ -f /etc/GNUstep/GNUstep.conf ] && \
         for i in `sed -e 's/\s=\s/=/' -e 's/^#.*$//g' -e
'/USER_GNUSTEP_D/!d' /etc/GNUstep/GNUstep.conf`; do export $i; done
IFS=$old_IFS
GNUSTEP_USER_ROOT=`dirname ${HOME}/${USER_GNUSTEP_DIR}/prune`

export GNUSTEP_USER_ROOT
- ------------------

I'd be happy to update you/everyone on what I am working on as soon as
the code isn't as scary as above. :-)

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.  gnustep-base is pretty much to the
point where it figures out paths correctly by itself, hopefully one
day removing 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. :-)

__Armando Di Cianno

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

iD8DBQFDTAcJwgiTPLI9xhcRAsGyAJ94oazH5VO66E5ByrbyD7RFkpwsWQCgjzG7
zjYm1ZarZpS6a3U9pmB59ic=
=0hnq
-----END PGP SIGNATURE-----