Re: gnustep-make on OSX

[Nicola Pero]

> > Yes ... I'd probably like to change the library combo for OSX from
> > nx-nx-nx to apple-apple-apple.
> >
> > In theory I should have kept support for the three building options, 
> > gnu,
> > nx, apple, as you say ... but it started to get complex, so I dropped 
> > the
> > oldest and (frankly) obsolete one.
> 
> While agree that the nx combo isn't really important, I can't follow 
> how it leads to complexity ? (I'm again somewhat frightend[how is this 
> word written ;-)] that library combos are going to be consider too 
> "complex").

I think I didn't explain myself. :-)

It's not that library combos are inherently complex.  Library combos are
very simple, they just work automatically. :-)

Here we are really talking about something different - it's that the
bundle structure of NeXTstep is different from the bundle structure of
GNUstep which is different from the bundle structure of Apple OSX.  

Having to keep an additional library combo is nothing :-) having to keep
support for an additional bundle structure complicates things, because I
then have three separate set of rules for building bundles, then three
separate set of rules for building frameworks, then three separate set of
rules for building applications ... because in all these cases the
property lists and the resources are located in different places, and
other minor differences.

I prefer to simplify things at the beginning.  It does simplify work.

If a target is totally obsolete (zero users), and no longer available on
the market (so there will never be new users), it simplifies my life to
just remove it, and I can spend more time on making the other active
targets better.

 
> > It's just to simplify maintaintenance that I did it.  I can rewrite and
> > recast code more freely this way.  I had no way to check the old code, 
> > and
> > looking at it, I also think it was already broken.
> 
> Hm, maybe. At least the old code contained code which once produced 
> valid NeXTstep entities and removing it altogether removes knowledge 
> ... ;-)

My point is that if by inspecting code I find out that the code is broken,
and has been so in the past 1 year, I must conclude that nobody is using
that code any more.

Deleting those lines from the new version doesn't remove knowledge,
because most of them are trivially rewritten if you inspect a NeXTstep
system, and btw you can always retrieve the deleted lines from CVS.

It is possible to add support for such bundles again.  If I rename the new
library-combo to 'apple', then support for the old 'nx' bundle structures
could be reimplemented in the future (it's very simple).

... but I can't see the number of users of gnustep-make on NeXTstep to
grow in the future, I can only imagine it's going to shrink, and since the
number of users is already 0 (zero), it looks like a bit pointless to
spend effort in maintaining it, I prefer to concentrate on the OSX code.


 
> >> BTW: A major problem is that Finder doesn't support reading 
> >> GNUstep.sh,
> >> which implies that you either need to start all GNUstep related
> >> programs (including PBX) from the shell or patch
> >> .MacOSX/environment.plist to include/define all required environment
> >> variables statically.
> > Hmmm.
> 
> I thought about that one. It's less a problem in practice. Since in the 
> nx-nx-nx combo GNUstep is only used for building, we can just use a 
> shell-script "gsmake" from PBX which sources GNUstep.sh and calls make.

Yes.

 
> >>> There is a particular trick which I have in mind to get there ...
> >>> which is
> >>> that library.make will actually build frameworks on OSX ... but I 
> >>> need
> >>> to
> >>> experiment with this.  :-)
> >>
> >> Hm, good idea ! This would solve me a lot of problems and does more or
> >> less exactly what I need.
> >
> > Ok - I'll go on with it.
> 
> :-) Is there already something new for OSX in CVS ?

I'm now actively thinking. :-)

I have libraries compile properly as libraries now (it's on CVS).

I will now add a flag which tells gnustep-make that a library should be
compiled as a framework on OSX.

But then, I can see the following problem - if you write an application
which depends on this library/framework, on GNUstep you would write

ADDITIONAL_GUI_LIBS += -lRenaissance

while on OSX if Renaissance is a framework, you would need

ADDITIONAL_GUI_LIBS += -framework Renaissance

Maybe the solution would be to have the conversion done automatically by
gnustep-make, or to use a new variable name and have gnustep-make add the
-l on gnustep, and the -framework on OSX.



> BTW: in OSX you can bundle frameworks in any bundle. Eg for 
> distribution you can add all required frameworks into the application 
> bundle. All this makes it very easy to install apps for the user.

Hmmmm.  Ok.

Well, as a personal comment, except for the resources, this is basically
statically linking the application to all the libraries it depends upon,
which generates very big executables.  Very easy to install, but very big.

I frankly prefer a lot more the package manager way of linux lands, which
installs (and uninstalls!) applications and shared libraries properly,
manage dependencies between things etc. :-)