libobjc and gnustep-make

[Nicola Pero]

There is a single missing scheduled bit before gnustep-make is ready for a
new release.

Basically, we want to change LIBRARY_INSTALL_DIR in library.make so that
it doesn't include the library-combo. 

Problem - this would break using a shared libobjc. 

Fixing that requires some thinking, if any of you have comments, they are
appreciated - here is some meat to put on the fire. 

One option is to write a clibrary.make which doesn't put the compiled
library into the library-combo, nor links against library-combo libraries,
but which (regardless of the name) allows also objc object files (trivial
to do), and then compile libobjc with that makefile.  This would require
no major change in gnustep-make and is probably the simplest path.

The second option is to move libobjc inside a library-combo dir.  but
then, we have to modify core/make/config* code to detect the libobjc
inside the library-combo ... or better, for *each* library-combo dir which
exists in $(GNUSTEP_SYSTEM_ROOT)/Libraries/$(GNUSTEP_TARGET_DIR), we need
to check if there is a libobjc there, and we have to get different thread
flags for each of them ...  then config.make will have different thread
flags and -L flags depending on which library-combo is being used ... 

and then modify gnustep-base when it extracts the flags from config.make
to extract the ones for that particular library-combo ... hmm 

It looks like much easier to follow the path of using clibrary.make, and
count on the fact that hand made shared libobjcs will be slowly made
obsolete by improvements in the standard gcc libobjc.  (they already
have).  Also, we don't get too much of a benefit from the change ... even
if yes, it does make sense to put libobjc in the library-combo dirs. 

Unless someone has intelligent suggestions or comments, I'll go for the
straightforward clibrary.make route.