Menu
▾
▴
wxlua-users
|
From: <af...@al...> - 2006-03-10 13:30:28
|
Here is how the Mac packaging works... (="will work")
Dual: just like Mac OS X itself, this can be done in
two different ways, the "Mac way" or the "Unix way"
(with the Mac way being more of the NeXT way really,
but that is a topic for a whole other discussion...)
--------------------------------------------------
1.
For the Mac way, I will do static links like this:
wxLua.app/
Contents/
Info.plist
MacOS/
wxlua
Resources/
wxLua.icns
wxLuaEditor.app/ (ditto)
LuaCan.app/ (ditto)
The "Info.plist" can be generated from Info.plist.in,
it's an XML file that describes the application...
This will not get "installed", but the user can drag
it to /Applications or ~/Applications, or wherever.
This "wxLua.app" bundle is what we set as the
application to launch for .lua files, and so on.
The Samples themselves will just go in a folder.
Package will be either ZIP or DMG, probably dmg ?
---------------------------------------------------------
2.
For the Unix way, it will be shared linked like:
$PREFIX/bin/wxlua ->
$PREFIX/lib/libwxlua_mac_wxlua-2.6.0.dylib
$PREFIX/lib/libwxlua_mac_wxbindstc-2.6.0.dylib
$PREFIX/lib/libwxlua_mac_wxbind-2.6.0.dylib
$PREFIX/lib/libwxlua_mac_wxluasocket-2.6.0.dylib
$PREFIX/lib/libwxlua_mac_wxluadebug-2.6.0.dylib
$PREFIX/lib/libwx_mac-2.6.0.dylib
That last library is not provided by wxLua,
it's the wxWidgets shared library being used.
(could be either wxMac or wxGTK, and either
monolithic or split into several - as usual)
$PREFIX/lib/libwx_mac_stc-2.6.0.dylib
$PREFIX/lib/libstedit.0.dylib
Will probably link STC and wxStEdit statically ?
(just to avoid problems in DarwinPorts and Fink)
On Mac OS X, "commandline" programs launch in the
background and don't receive any events (sucks!),
so we will fake this for the "Unix way" by adding
an oldskool Mac resource fork, including the icon:
/Developer/Tools/Rez -d wxLua.r Carbon.r -o $PREFIX/bin/wxlua
/Developer/Tools/SetFile -a C $PREFIX/bin/wxlua
This will make it look nice, and : receive events too. :)
All these files will get installed, in the usual $PREFIX.
---------------------------------------------------------
Hope that clears things up ? Mac OS X is a strange hybrid...
--anders
|
|
From: Francesco M. <f18...@ya...> - 2006-03-10 14:21:39
|
Anders F Björklund ha scritto: > Here is how the Mac packaging works... (="will work") > > Dual: just like Mac OS X itself, this can be done in > two different ways, the "Mac way" or the "Unix way" > (with the Mac way being more of the NeXT way really, > but that is a topic for a whole other discussion...) > > -------------------------------------------------- > > 1. > For the Mac way, I will do static links like this: > > wxLua.app/ > Contents/ > Info.plist > MacOS/ > wxlua > Resources/ > wxLua.icns > wxLuaEditor.app/ (ditto) > LuaCan.app/ (ditto) > > The "Info.plist" can be generated from Info.plist.in, > it's an XML file that describes the application... > > This will not get "installed", but the user can drag > it to /Applications or ~/Applications, or wherever. > > This "wxLua.app" bundle is what we set as the > application to launch for .lua files, and so on. > > The Samples themselves will just go in a folder. > Package will be either ZIP or DMG, probably dmg ? > > --------------------------------------------------------- > > 2. > For the Unix way, it will be shared linked like: > > $PREFIX/bin/wxlua -> > $PREFIX/lib/libwxlua_mac_wxlua-2.6.0.dylib > $PREFIX/lib/libwxlua_mac_wxbindstc-2.6.0.dylib > $PREFIX/lib/libwxlua_mac_wxbind-2.6.0.dylib > $PREFIX/lib/libwxlua_mac_wxluasocket-2.6.0.dylib > $PREFIX/lib/libwxlua_mac_wxluadebug-2.6.0.dylib > $PREFIX/lib/libwx_mac-2.6.0.dylib > > That last library is not provided by wxLua, > it's the wxWidgets shared library being used. > (could be either wxMac or wxGTK, and either > monolithic or split into several - as usual) > > $PREFIX/lib/libwx_mac_stc-2.6.0.dylib > $PREFIX/lib/libstedit.0.dylib > > Will probably link STC and wxStEdit statically ? > (just to avoid problems in DarwinPorts and Fink) > > On Mac OS X, "commandline" programs launch in the > background and don't receive any events (sucks!), > so we will fake this for the "Unix way" by adding > an oldskool Mac resource fork, including the icon: > > /Developer/Tools/Rez -d wxLua.r Carbon.r -o $PREFIX/bin/wxlua > /Developer/Tools/SetFile -a C $PREFIX/bin/wxlua > > This will make it look nice, and : receive events too. :) > All these files will get installed, in the usual $PREFIX. > > --------------------------------------------------------- > > Hope that clears things up ? Mac OS X is a strange hybrid... this helped indeed to understand Mac world ;) So, we just need to add to build\macbundle the Info.plist and maybe a simple script which calls the utilities to actually build the package, isn't it? I can then add Info.plist to configure list of files to create. It won't be used by Unix installations but only by Mac ones... Francesco |
|
From: <af...@al...> - 2006-03-10 14:39:17
|
Francesco Montorsi wrote: > So, we just need to add to build\macbundle the Info.plist and maybe a > simple script which calls the utilities to actually build the package, > isn't it? > > I can then add Info.plist to configure list of files to create. It > won't be used by Unix installations but only by Mac ones... Something like that, yes... Just that we'll need one such Info.plist for all three apps, or do a common template for all and generate the specifics ? (I guess the version numbers of them would follow wxLua's ?) For an example of what it looks like, you can view: http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist It's missing the bindings to certain filetypes, though. Building the app can be a small shell script (or Makefile) I don't actually think we'll even need an Installer PKG... (better to do an RPM spec file in that case, and use RPM ?) --anders |
|
From: Francesco M. <f18...@ya...> - 2006-03-10 14:55:03
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >> So, we just need to add to build\macbundle the Info.plist and maybe a >> simple script which calls the utilities to actually build the package, >> isn't it? >> >> I can then add Info.plist to configure list of files to create. It >> won't be used by Unix installations but only by Mac ones... > > Something like that, yes... > > Just that we'll need one such Info.plist for all three apps, > or do a common template for all and generate the specifics ? > (I guess the version numbers of them would follow wxLua's ?) I would keep them separed as they look like short XML files. And yes, the versioning will be the same. > > For an example of what it looks like, you can view: > http://www.algonet.se/~afb/wx/CodeBlocks.Info.plist > It's missing the bindings to certain filetypes, though. Seems not too complicated - let me know if you can send me these file within today so that they could be included in the source package. > > Building the app can be a small shell script (or Makefile) sure - just choose the one you prefer. > I don't actually think we'll even need an Installer PKG... this gives me some other conceptual problem: Installer PKG was not mentioned in point 1) or 2)... I thought we were going to release a .dmg... > (better to do an RPM spec file in that case, and use RPM ?) RPM is evil as it is distro- and version-distro- specific. That's why I'm using autopackage for Linux binary package. So I'd prefer to avoid it... Francesco |
|
From: <af...@al...> - 2006-03-10 15:09:05
|
Francesco Montorsi wrote: >> I don't actually think we'll even need an Installer PKG... > this gives me some other conceptual problem: Installer PKG was not > mentioned in point 1) or 2)... I thought we were going to release a > .dmg... Normally you wrap a PKG inside a DMG, if you need to get permission or install in "invisible" directories (the Finder hides /usr/local and the rest from the user) For wxLua, we're not really going to distribute the bin and lib and so on to the "end user", so we can let users wanting those use source or DarwinPorts/Fink ? Thus, we won't require PKG in this project. Right you are. Making a DMG is pretty simple, just proprietary to Apple: hdiutil create -srcfolder wxLua -fs HFS+ -format UDZO -ov wxLua.dmg hdiutil internet-enable -yes -quiet wxLua.dmg >> (better to do an RPM spec file in that case, and use RPM ?) > RPM is evil as it is distro- and version-distro- specific. > That's why I'm using autopackage for Linux binary package. > So I'd prefer to avoid it... huh ? I was just talking about a .spec file, for building RPMS yourself ? You don't even have to distribute SRPMS, as one can use the tarball. Nothing evil about that, I like RPM. Binary RPMS, however: Oh dear... :-) --anders |
|
From: Francesco M. <f18...@ya...> - 2006-03-12 12:36:27
|
Anders F Björklund ha scritto: > Francesco Montorsi wrote: > >>> I don't actually think we'll even need an Installer PKG... >> this gives me some other conceptual problem: Installer PKG was not >> mentioned in point 1) or 2)... I thought we were going to release a >> .dmg... > > Normally you wrap a PKG inside a DMG, if you need to > get permission or install in "invisible" directories > (the Finder hides /usr/local and the rest from the user) > > For wxLua, we're not really going to distribute the > bin and lib and so on to the "end user", so we can > let users wanting those use source or DarwinPorts/Fink ? > > Thus, we won't require PKG in this project. Right you are. ok > > Making a DMG is pretty simple, just proprietary to Apple: > hdiutil create -srcfolder wxLua -fs HFS+ -format UDZO -ov wxLua.dmg > hdiutil internet-enable -yes -quiet wxLua.dmg maybe these cmds should go into a script in build\macbundle ? > >>> (better to do an RPM spec file in that case, and use RPM ?) >> RPM is evil as it is distro- and version-distro- specific. >> That's why I'm using autopackage for Linux binary package. >> So I'd prefer to avoid it... > > huh ? > I was just talking about a .spec file, for building RPMS yourself ? > You don't even have to distribute SRPMS, as one can use the tarball. > > Nothing evil about that, I like RPM. ah, ok; I strongly associate RPM with the idea of binaries, maybe because I've never used SRPM... ;) > Binary RPMS, however: Oh dear... :-) :) Francesco |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X