> Did these get added in the end? Without them, -make is likely to be broken > in a number of configurations.
I added them. Testing is welcome. I guess gnustep-make is ready for release (subject to testing, and fixing the -Wl,-r / -mno-relax issue). ;-) A last bit I was thinking of doing was deprecating objc.make. objc.make is meant to be used to compile Objective-C programs (not libraries) without the use of any Foundation library. This is not really that useful, and it will become increasingly hard to support. Let me explain. At the moment, using your own custom libobjc (for example, but not limited to, libobjc2) is quite cumbersome: * configure/make/make install in gnustep-make (and you need to have some sort of libobjc already here to bootstrap the process!) * make/make install in your own libobjc * configure/make/make install in gnustep-make (again!) to detect the new libobjc * configure/make/make install in gnustep-base It would be good to remove the requirement to reconfigure/reinstall gnustep-make after installing your custom libobjc to make the process easier. This suggests the following setup: * gnustep-make's configure would contain checks for compiler capabilities that do not depend on the runtime, so that we know what flags to use when compiling C/ObjC (required to compile custom libobjcs properly!) * gnustep-base's configure would contain checks for runtime capabilities, so if you change your runtime, even significantly, you still don't have to reconfigure/reinstall gnustep-make. You just go straight to gnustep-base as gnustep-make does not depend on the runtime. :-) I did follow this logic when implementing the checks for the Objective-C native exceptions. So, gnustep-make checks that the compiler supports them (but you don't need a runtime installed with support for them yet), then gnustep-base checks the runtime support (and can still disable native exceptions if no satisfactory support is found). At the next release (too late for this one) we'll do a similar change for the threading flags and eradicate any dependencies of gnustep-make on the runtime, so we can simplify using custom ObjC runtimes. :-) But, the big disadvantage is that objc.make becomes harder to support; once gnustep-make contains no code that depends on the runtime, it wouldn't know what flags to use to compile/link with that runtime if gnustep-base is not used, so objc.make makes no longer particularly sense. As nobody is using objc.make as far as I know, I was thinking of deprecating it (not removing it, just deprecating it) in this release. It's important to deprecate early because we don't remove deprecated things from gnustep-make for many many years. ;-) The removal of objc.make doesn't mean we don't want to support building with other ObjC libraries or things; if anyone has any such requirement, please talk to me. It would make sense in most cases to reuse library.make, tool.make etc. and use a custom additional makefile fragment in the way that gnustep-base does it, which is quite easy to setup. Comments / suggestions welcome! :-) Thanks _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
