[wx-dev] Making a Mac PKG for wxWidgets

[Anders F Björklund]

Kevin Ollivier wrote:

> First off, thanks for your hard work on this!

No problem, thought that I would contribute it upstream...

>> I ran the Apple "install_name_tool" on the library, to rename it to 
>> framework:
>> install_name_tool -id 
>> @executable_path/../Frameworks/wx.framework/Version/A/wx
>>
>> Probably is cheating, but Apple doesn't have a good alternative that 
>> doesn't
>> involve using Xcode and I didn't feel like relying on another 
>> proprietary tool.
>
> Looking at the Carbon framework, 
> /System/Library/Frameworks/Carbon.Framework/Carbon is just a symlink 
> that points to Versions/Current/Carbon. Cocoa, OpenGL, etc. do the 
> same thing. Is there a reason creating a symlink wouldn't work for the 
> wx case, too?

I think you are talking about two different things, as I did add such a 
symbolic link.
The install_name_tool changes what it actually links to, and that 
includes a version ?

If you look at: otool -L 
/System/Library/Frameworks/Carbon.Framework/Carbon, you will
see that it is named: 
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon

This is similar to how .so and .dylib files work, both in Linux and in 
plain Darwin:
i.e. libwx_macu-2.6.dylib -> libwx_macu-2.6.0.dylib, one "devel" and 
one "runtime" ?

> If you could post the scripts, or explain more about what steps you 
> took to build this, we'd really appreciate it! :-) We already do run 
> scripts to build PKG/DMG packages for wxPython, so the big piece 
> that's missing is the series of steps for turning a wxWidgets build 
> into a Framework.

Not a problem, I'll just need to clean it up and document it a little 
better too.
Guess I should try to overcome my fear of snakes and actually try 
wxPython too...

> In addition to that, though, if we want Apple to use this and provide 
> an 'official' wx framework, we'll need to still support 'old' style 
> "wx/whatever.h" includes, so that existing apps will build with it 
> too. (i.e. we'll have to support something like Apple's FlatCarbon 
> headers.) wx-config should use the 'flat' headers by default, again as 
> that's what existing apps need. We can probably add some sort of 
> wx-config --osx-framework --cxxflags command (or maybe 
> wx-framework-config?) to get the cxxflags without the wx include 
> paths, as your Commands/wx-config command appears to do.

I just diked out the parts of the script that set the paths, and added 
a little framework search.
I'm sure there's a better way to do it, though :-) But you only need to 
do the FlatHeaders thing
if you decide to name it "wxWidgets.framework" or something (i.e. 
instead of just wx.framework)

You *could* do what Apple tries to do with OpenGL.framework, have the 
world change their #includes.
But I don't really recommend it, I think most people would like to keep 
<GL/gl.h> and <wx/wx.h> ?
(instead of them changing to <OpenGL/gl.h> and <wxWidgets/wx.h>, for 
their Mac OS X builds only)

>>> AFB> I'm not sure to handle add-ons like GL or STC, but
>>> AFB> they could probably go in the Libraries dir perhaps ?
>>> AFB> (or maybe even be merged into the main dynamic library,
>>> AFB> since OpenGL is always available on a Mac OS X platform)
>
> I'm not sure exactly about how the add-ons should be handled, either, 
> especially since contribs are currently built separately. But for the 
> moment, we can at least put them in Libraries, and have wx-config give 
> the right linker flags, and then later look at how we can merge 
> everything into one.

It's easy enough to find the libraries at development-time, the real 
problem is for run-time ?
You see, that Libraries sub-directory is not part of any system search 
paths or anything...

--anders