Re: bundlelisation of the backend

[Nicola Pero]

Now making the backend a bundle looks like a major change - in better - to
me.

> I think it's useful to do this, particularly to refine the separation
> between gui and the backend. 

Yes - making it simpler.


> > 3) make package should be modified because now, GUI apps don't need to
> > be link with any specific backend. But I'm not competent to do it.
> > 
> 
> That's almost not necessary.

Well - if the backend becomes a loadable bundle - smile - that's nice -
then the library combo can be simplified, can't it ? - we remove the last
part of the combo, because executables and libraries do no longer depend
on it.  At run-time, the gui itself will decide (when it initializes
itself in code triggered by NSApplication +sharedApplication), basing on
command line arguments or user defaults or shell variables, which backend
to load in.  Other gui libraries (apple one) do not need the backend part
of the library combo anyway, so it becomes totally useless.  And now
that's very nice.



> What about static and profiled executables?

Well - loading the backend as a bundle looks like meaning you can't create
a totally static executable - I mean you could at most have a statically
linked executable, a statically linked bundle, but still you load the
bundle at runtime...

Rather (or is it the same problem) - what about executables making X calls
(for xgps) directly ? They need to be linked with X directly otherwise you
get undefined symbols. <well you could put the code accessing X in a
bundle, and then load the bundle after the backend bundle, but we want it
to be easier than that>. <when I talk about X I just mean `the underlying
graphical libraries used to implement a backend'>

One idea which pops to my mind - not sure it is workable or good though -
is that we could make a clear separation between executables only
accessing gui stuff through the gui and special ones making occasional X
calls directly.  Then, we would have two different backend bundles.  One,
linked with all the X libraries.  That one is the standard one.  Standard
executables only using the gui just load that backend at run-time.  They
depend in no way on X.  Instead, special executables containing X calls
will be linked directly with the X libraries.  To avoid conflict, these
executables will then load a special version of the backend bundle, which
is not linked itself with the X libraries.  The bundle can contain
undefined symbols, so that doesn't look like a problem.

So, the arrangement would be as follows - when we compile the backend
bundle, we compile two of them - one linked with all the X libraries, the
other one *not* linked with any of the X libraries.  In xgps.make, we have
two different sets of flags, switched by some make variable such as
USES_SYSTEM_GRAPHICAL_LIS_DIRECTLY.  If that variable is empty, we just do
no link with any library (the backend already has them all); if it is set,
we plug in all the flags needed to link the application directly with all
the X libraries used/needed by the backend.  We also have to tell the
application that at runtime it needs to load the special bundle without X
libs.  We could write that information into the info.plist file or better
plug it in someway into the executable.  Perhaps link in a tiny library
which only defines a symbol, and in the gui code decide on which bundle to
load basing on that symbol.  I don't know - any ideas or comments ?