[wx-dev] Supporting MacOS X frameworks

[Anders F Björklund]

Etienne Samson wrote:

>> I totally agree with the desire to have a Mac OS X native shared 
>> library packaging.
>> Suggested /Library/Frameworks/wx.framework, only for automatic 
>> <wx/wx.h> includes ?
>
> Hmm, this is a little complicated...
> Right now, mose of wxWidgets use #include 's in the form of "wx/foo.h" 
> (or "wx/bar/foo.h"), which is good when something provide the missing 
> part of the path (/usr/local/include generally, provided by 
> wx-config). For a framework to work on a completely automatic way, 
> these "wx/foo.h" should be changed to just "foo.h" (or "bar/foo.h"), 
> so you do need to use wx-config to tell you the start of the path. 
> There is two possibilities right now, change everything as I said, or 
> provide the missing part of the path. I chose the latter (since it 
> doesn't require me to change more than a thousand files) by providing 
> the "/Library/Frameworks/wx.framework/Headers/" path in the project 
> that use it.

I'm not sure I follow. Naming the framework "wx" instead of wxMac or 
wxWidgets was precisely *for* the reason that the currently used 
<wx/wx.h> would continue to work, and avoid the "<OpenGL/gl.h> 
syndrome" where you would use one include path on Mac OS X and another 
path on all other systems. Otherwise it could have been called 
wxWidgets.framework instead.

With the Mac OS X version of GCC, include <foo/bar.h> means either to 
look in include/foo/bar.h or in foo.framework/Headers/bar.h - searching 
in all the usual prefix locations for includes and frameworks. You 
could of course add the "Headers" directory of the framework to -I 
manually.

>> My workaround for the Mac OS X 10.3 vs Mac OS X 10.4 issue was to use 
>> ANSI for Panther and UNICODE for Tiger, I'm sure it could be solved 
>> in another way (e.g. build two and lipo)
>
> I still haven't got any problem with this, if you could give me 
> directions on how to trigger an error on that, I could test the 
> framework to ensure that everything works fine...

Just a little matter on which compiler to use (GCC 3.3 vs 4.0) and 
which SDK to use (10.3.9 vs 10.4.0u), but I think the Xcode projects 
are set up differently for the two architectures ? (i.e. it builds PPC 
for 10.3 and X86 for 10.4, or something like that - haven't looked into 
the details)

>> In theory that should make it pick up bundled frameworks, user 
>> frameworks, local frameworks, system frameworks, local libraries, 
>> system libraries, Fink libraries, DarwinPorts libraries ?
>
> In theory, yes, but you still need to install stuff into /usr (or 
> anything else), or install then copy it in the appropriate place 
> inside the Framework.

Yes, it still needs to be installed somewhere along the search path 
(libraries or frameworks). I just thought that if I named it 
"libwx_macu-2.6.0.dylib" rather than just "wx", it could still find the 
regular shared libraries too and not *require* that the user installed 
it as a framework ?

> The thing that seemed strange to me was that there is a Xcode project 
> file, but it is only used to build static and dynamic versions of 
> wxWidgets, while it could also be modified to build a framework (This 
> is what I'm doing). In general, if I wanted to build things 
> static/dynamic, I could go the classic configure/make way, and use 
> Xcode to build a framework...

I think the "dynamic" target should be changed into a framework instead 
of using raw dylibs, so I agree with you there. But I haven't used the 
Xcode projects for wx yet, just the command-line. A little problem is 
having several libraries in one framework, so I just built wxWidgets as 
monolithic.

>> If one absolutely doesn't want frameworks, I guess there *could* be 
>> an installer PKG done that would install the includes and dylibs in 
>> /usr (like how Apple does it for their Tiger installation).
>
> I have my little idea that Apple did it that way because they didn't 
> care about turning wxWidget into a framework, and so used what was in 
> place (configure / make). Although I have no problem going that way, 
> it seemed a little awkward not to use the framework system since 
> wxWidget is a library, so it can be easily bundled, installed and 
> removed from one's computer.

I'm not sure what they did and did not do, since it wasn't useful to me 
anyway.
I think that Leopard will do it better, but I don't want to force an 
upgrade...

Just think that if I wanted a UNIX install, I would use a real package 
manager.
(DarwinPorts works just excellent for installing wxMac/wxGTK/wxMSW on 
Mac OS X)

> Anyway, I'll look into making everything work fine, then put this onto 
> Sourceforge for inclusion in CVS, and provide pre-packaged and easy 
> installable/usable frameworks.

Sounds good, the emphasis is on automated build scripts - see wxPython 
for examples.

--anders