Re: More Windows stuff ... Gorm works ... sort of

[Nicola Pero]

> > Btw, I think you both missed my point ;-)
> > 
> > .... if an application is built using "simple" / "standard" mechanisms
> > (like: building a shared library, building a bundle, linking an object
> > file to a shared library) then porting to new platforms will be easier,
> > because once those "standard" mechanisms are implemented, your application
> > will be automatically ported.  Linking a loadable bundle against an
> > application is always going to be implemented *after* linking a loadable
> > bundle against a library.  So if you depend on support for linking against
> > a library (rather than on linking against an application), the stuff is
> > more easily portable.
> 
> You are correct ... I did miss that point.
> 
> But I think that linking against the application is of the essence of a
> bundle, so while it may be harder to port, it is necessary.

I agree with you that this might be nice and useful to have ... :-)



> From the point of view of a developer using GNUstep (rather than someone
> maintaining/writing the gnustep core) the correct behavior of bundles is
> something that should just be assumed.  In other words, I don't think this
> is an issue that Gregory should need to consider in his design, rather it's
> an issue that we need to resolve in make/base so that he and others like him
> can work productively.

... but I still think that assuming advanced building features in "core"  
components is not a good idea.  Gorm is a "core" component and it would be
nice if it was very portable and worked almost automatically as soon as
the very basic stuff is ported to a platform.

GNUstep was ported to Windows years ago, yet it took ages for Gorm to work
on Windows just because of this 'linking bundles to the application'
issue.

I'd definitely suggest choosing a building strategy which works out of the
box using just the basic building blocks (libraries, apps, linking to
libraries, loadable bundles).



> > Finally I don't understand why those palettes are loadable palettes at all
> > (and are not just linked directly into Gorm) if they access Gorm internals
> > directly so heavily ... why don't you link them directly into Gorm ?
> > Then building Gorm on a platform would only depend on shared libraries and
> > applications, and would be really easy to port ...
> 
> I don't know the current design ... but I can answer from a historical
> perspective.
> When I wrote the standard palettes, they used only the public API to access
> Gorm and didn't depend on special access to the internals (I don't know if
> that's still the case).  They were written as palettes precisely so that I
> could test that palette loading worked and that the public API from Gorm
> worked to let people write their own palettes.

I'm not sure what the public API from Gorm is, if there is one, I think
it's supposed to be GormLib, so palettes could just link against GormLib
and access that public API, but when I mentioned that Gregory said the
standard palettes need to access some more complicated Gorm internals
directly and that GormLib is supposed to be a clone of some other Apple
framework, so I don't know what public API Gorm has got or if it has got
one ... if Gorm has got a public API I suppose that should go in public
headers ...

... and now IMO this is just the core of the issue ... if Gorm has got a
public API with headers and symbols you access and need to link to, it
should be turned into a library ... that's how you normally read headers
and link to on most platforms.

If that means most of Gorm ends up in a library, I don't see what's wrong
with that, you could have most of it in a library, and the Gorm.app
application could just be a 'main' routine linked to the library and
starting the code up.

Then palettes could use the Gorm library headers and link against the Gorm
library (including custom palettes, which could do the same); and once
shared libraries (and loadabale bundles) work on a platform, everything
would just build and work.

Anyway, I appreciate all your points etc, I just think it's a shame it
took so long to get Gorm working and it might have been so much easier if
the building process had been more standard, so I'm trying to suggest
possible ideas to make it more standard. :-)

I think I proposed enough variants so I'll drop off at this point ...  
;-)

Thanks