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