Re: Totally Gormless

[Nicola Pero]

> 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 ?



> Honestly, I think OPTFLAGS should be removed because:
> - - if you use a binary distro, it doesn't matter
> - - if you are compiliing by hand "export CFLAGS="-fmy-flags" should
> work just fine
> - - if you use a source base distro, CFLAGS is generally managed from
> one location
>

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.

 

> > 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 ?

 
> 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. ;-)

Thanks