[wx-dev] [wxMac] distributable frameworks builds

[Anders F Björklund]

Stefan Csomor wrote:

> I'm currently experimenting with a similar setup, I compared to the
> framework build of python, so I copied essentiall the 'install' folder
> of a prefixed build into Versions/2.8, and symlinked Headers wx and
> Current
>
> but we still are left with the single dylib pointed to by such a wx
> symlink, which I'd really like to avoid ...

Why do you want to avoid the symlink ? If you name it "wx" instead
of something else, then you'll get conflicts from different ports ?

Besides, one of the ideas of having "wx" be the same as the regular
library was that it could use the regular shared libraries too.
(i.e. if it doesn't find any wx.framework on the search path, but
it does find a libwx_macu-2.6.0.dylib on the library search path)

> so we'd have a wx_select command, this could work out, yes ...

A wx_select command could work. Or you could just re-install the
framework you want to use and it would overwrite the symlinks ?

wxCocoa is lacking several important features* for me right now,
but I just wanted to keep the option open for the Mac OS X future.
* = drag-and-drop, printing, wxFlatNotebook, and the other C::B stuff
that is currently works OK using wxMac and doesn't work with wxCocoa

>> There is no difference between bundling this in Resources and
>> installing it in share/wxwidgets, though. Just naming standards ?
>
> if we conform to the naming standards, then the OS could help us with
> loading of things, like eg a multi-resolution tiff image, things like
> nibs could refer to standard resources, so it might make that easier,
> but it is just something I'd like to keep in mind, not something
> mandatory

Yeah, but what standard ? Confirming to Mac OS X standards doesn't
help with cross-platform portability, how do I load a NIB on Linux ?
If the implementation needs to use such OS things, then so be it, but
I would like to be able to write against just the wxWidgets "platform".

So for the moment it would probably be for the best if the wxWidgets
implementation did everything in code, without requiring outside files ?

>> I would prefer if both Xcode and configure built the same library
>> (bundled or not),
>
> I agree on that, but I'd like to experiment a little whether I find a
> way to build a framework from the dylibs so that the multilib would 
> work

Yeah, it could be nice to have those. Or optionally include GL and STC
too in the monolithic library, that would work for most of my own uses 
;-)
Or do you plan on making wx.framework into an umbrella framework 
instead ?
Not sure what that would buy us, can't link against sub-frameworks 
anyway.

BTW; what's the problem with the monolithic lib, besides it being 
larger ?
(think my Mac OS X 10.4 build of wxWidgets currently weighs in at ~25 
MB)

--anders