GNUSTEP_LIBRARIES reflections

[Nicola Pero]

Hi, I'm half asleep and I was thinking about makefile chunks so I
thought I would mention here some private rants about some makefile
internals which I might be going to change once ideas have cleared up
- just in case someone has something relevant to say - it's sort of
brainstorming.

The main problem is the gnustep-make API for installation directories
and stuff which is confused and unsatisfactory.

The main problem in the API is GNUSTEP_LIBRARIES.  While, say,
GNUSTEP_APPS is $(GNUSTEP_INSTALLATION_DIR)/Apps, and GNUSTEP_TOOLS is
$(GNUSTEP_INSTALLATION_DIR)/Tools and GNUSTEP_BUNDLES is
$(GNUSTEP_INSTALLATION_DIR)/Library/Bundles, GNUSTEP_LIBRARIES is
inconsistently
$(GNUSTEP_INSTALLATION_DIR)/Libraries/$(GNUSTEP_TARGET_DIR)/$(LIBRARY_COMBO),
that is, it contains the full target dir and library combo.  To get
the simple $(GNUSTEP_INSTALLATION_DIR)/Libraries you have to use the
special variable GNUSTEP_LIBRARIES_ROOT.

But the confusing API doesn't stop here.

If you want to install your bundle somewhere else, you do as in

BUNDLE_INSTALL_DIR = $(GNUSTEP_INSTALLATION_DIR)/Libraries/Adaptors

and that is consistent with the fact that BUNDLE_INSTALL_DIR defaults
to be $(GNUSTEP_BUNDLES).

If you want to install your library somewhere else, you have to do as
in

LIBRARY_INSTALL_DIR = 
$(GNUSTEP_INSTALLATION_DIR)/Libraries/Internals/$(GNUSTEP_TARGET_DIR)/$(LIBRARY_COMBO)

which is probably consistent with the fact that LIBRARY_INSTALL_DIR
defaults to $(GNUSTEP_LIBRARIES), but it is totally inconsistent with
BUNDLE_INSTALL_DIR, because in the case of libraries you have to
specify the target and the library combo, while for bundles (and
tools, and anything else) you don't.  Btw, it's also clumsy to have to
specify the library combo.

The idea behind all this might be that you might want to compile a
library which does not depend on the library combo, so you want to
install it into $(GNUSTEP_LIBRARIES)/Libraries/$(GNUSTEP_TARGET_DIR)
without the $(LIBRARY_COMBO) part, and LIBRARY_INSTALL_DIR would allow
you to do this.  But as it is clearly seen, this is absolutely
inconsistent with what is done for tools, where you have a special
variant of tools which is not linked against library combo libraries,
and which is not installed into the library combo directory - which is
the ctool project type.

So we would need a totally different makefile, which I would call
something like clibrary.make to make it similar to ctool.make; this
makefile would not link in any of the library-combo libraries at the
link stage, and would then automatically omit to add the LIBRARY_COMBO
part.

Someone might say that the difficult exception is GNU libobjc - which
is not a C library as it contains ObjC code, but which we currently
put outside LIBRARY_COMBO, only I consider this to be wrong, as the
runtime library depends of course on the compiler generating code for
the correct GNU runtime when compiling it, so it's dependent on the
type of runtime you compile it for, and you can't mix it with code
compiled for a different runtime (or more clearly you have as many
problems in trying to do this as with any other runtime specific
library), which really means it's absolutely runtime specific and thus
should be imprisoned into a library-combo keyed directory.  I know
that means if you have two different foundation libraries, then you
have to compile the runtime library twice for the two different
libraries, but that's life with library-combos, that's because the
library-combos include the runtime, and it's not gonna change unless
we get revolutionary and modify the library combo thing into a longer
directory tree, so that we would install stuff into:

xxx/ix86/linux-gnu/: non library-combo-dependent stuff
xxx/ix86/linux-gnu/gnu/ : stuff dependent on the runtime only
xxx/ix86/linux-gnu/gnu/gnu : stuff dependent on the runtime and
                             base library
xxx/ix86/linux-gnu/gnu/gnu/gnu : stuff dependent on the
                                 runtime, base library, and gui library

that is not unreasonable in my opinion.  C tools would go into

xxx/ix86/linux-gnu/

the ObjC runtime library would go into 

xxx/ix86/linux-gnu/gnu/

the base library, and normal ObjC foundation-based tools would go into

xxx/ix86/linux-gnu/gnu/gnu/

the gui library, and applications, and anything gui, would go into

xxx/ix86/linux-gnu/gnu/gnu/gnu/

that would make sure you only compile twice things you need to compile
twice - eg not the objc runtime library - but also it'd be nice to
have the command-line tools not contain the gui library combo part
anywhere ... [it also starts a completely new train of thoughts ... if
you are using GNU ObjC, base library and an ObjC gtk wrapper, you
might want to have your stuff put into xxx/ix86/linux-gnu/gnu/gnu/gtk
... you just set `gui = gtk' at the begin of your makefile, you
install a custom gtk.make makefile which sets the correct gui flags
ifeq ($(GUI_LIB),gtk) and from the point on you can use
application.make, library.make, bundle.make etc and everything will
install and search libraries into gnu/gnu/gtk ... without having to
recompile the base library for that !]

But that would also roughly double the number of -L flags on the link
line ... which is already huge ... so I'm not sure if it's a good idea
and I'm leaving it (or perhaps we might turn it on with a gnustep-make
configure switch, as for flattened stuff).


Anyway, the following set of changes is rumbling in my head from a
couple of days:

GNUSTEP_LIBRARIES will simply be $(GNUSTEP_INSTALLATION_DIR)/Libraries
(of course, GNUSTEP_FRAMEWORK_LIBRARIES etc will have the same fate;
GNUSTEP_LIBRARIES_ROOT and GNUSTEP_TARGET_LIBRARIES will be removed).

LIBRARY_INSTALLATION_DIR in library.make will default to
$(GNUSTEP_LIBRARIES) which now means the target dir and library combo
will be added automatically by library.make and should *not* be added
by the user GNUmakefile

a new clibrary.make makefile for libraries not depending on the
library combo will be added.  This makefile will do the same as
library.make, but will not link against any library combo library, and
will not add the library combo part to the installation path.  This
makefile will only be useful for C stuff, as if you compile ObjC code,
you have to tell the compiler which runtime you're generating code
for, so you're automatically getting into the library-combo business
because the generated code only will run when linked with that
particular runtime library (the case that the library is the runtime
library itself makes no exception, it only works with that runtime).

additionally, we might think of merging the ctool and clibrary
makefiles into the tool and library ones, perhaps ctool.make and
clibrary.make might simply include tool.make and library.make after
setting some NO_LIBRARY_COMBO_CODE variable which will modify
tool.make and library.make behaviour not to link against library-combo
stuff and not to add library-combo stuff to object paths and
installation paths.  Perhaps a better name for that variable should be
chosen, and it would be used everywhere, so any target could be run in
no-library-combo mode just by setting that, say
xxx_NO_LIBRARY_COMBO_CODE = yes.  We would still provide ctool.make
for backward compatibility.

The main reason I have not yet put any of this into existence, is that
the library API changes might break existing makefiles which where
relying on the previous (even documented) behaviour of
GNUSTEP_LIBRARIES and LIBRARY_INSTALLATION_DIR.  I think by defining a
backward-compatibility deprecated GNUSTEP_LIBRARIES_ROOT (to be the
same as it was before, and the same as the new GNUSTEP_LIBRARIES) we
should minimize damages, for the following reasons:

<note: libobjc is an exception as it uses both
LIBRARY_INSTALLATION_DIR and GNUSTEP_TARGET_LIBRARIES but it's because
it's trying to install outside the library-combo, I don't think any
other libraries do>

LIBRARY_INSTALLATION_DIR was introduced in January 2001, and was
seriously buggy (wasn't creating installation directories) till some
days ago - so I suppose few people if any are using it.

GNUSTEP_LIBRARIES_ROOT would still be there using the
backward-compatibility definition.

GNUSTEP_TARGET_LIBRARIES and GNUSTEP_LIBRARIES - I don't think these
are used anywhere.

Because we have introduced variables representing gnustep-make
versions, if we raise the version numbers after the backwards
incompatible changes, as a last resort makefiles can still be written
which run both on old systems than on new, they simply need to check
GNUSTEP_MAKE_VERSION and include different code according to that.