John Labenski wrote: > Ok, this is getting a little too complicated for me.
Didn't mean to confuse you :-) > Bottom line: Does it even make sense to write a script that after > compilation creates a dir named wxLua.framework, copies all the bits, > and create the links? Basically, we rewrite copydylibs.command to make > this dir structure, similar to wxLua-2.4.1-tiger.dmg, but following > the Framework dirs. Then... we have to worry about how and where to > install it and the apps. Well, the structure of the download disk image is just *the same* as you get from the tarball - just with the binaries already built so that you can run them directly... > If mimicking a Framework dir structure makes sense could you suggest a > structure you think would be good? I get the impression that the > full-blown framework not what you think is right, but how about a > pseudo-framework like dir structure that wraps everything, includes, > libs, apps and the installer creates links to parts within it. I'm not so sure about the "pseudo-framework" approach, Python and Java uses this - and it is rather confusing. It usually has some "compat settings" to help adopting, but somewhere along the weirdo paths it always shows :-) Usually you need a complex set of symlinks, to make it look like a regular directory setup. Makes you wonder why one wouldn't just provide those directories in the first place, but instead make it look like a .framework ? i.e. converting "include" and "lib" into Frameworks is OK. Adding "bin" and "doc" and a lot of others probably isn't. > If not, that's fine and copydylibs.command can be updated and we'll > stick with the dir structure of wxLua-2.4.1-tiger.dmg. This is my preferred approach, updated with any changes of course. (i.e. make it the same structure as the wxLua source tarball has) > Regards, > John > > ps. I responded to some things below, but it seems like there's too > many little bits and the real question is simply "wxLua-2.4.1-tiger > structure or some new dir structure?" Replying below, but I would go with the old in-source layout until you are ready to do a binary-only distribution of it ? (such as one with just a wxLua.app and nothing else inside) Preferrably it should match Windows and Linux distributions. --anders >>> Could it more easily solve the copydylibs.command problem of how to >>> make the wxLua libs accessible? >> >> Using dylibs isn't really a problem, more of a design decision. > > You mean dir design right? Well, dir design or packaging design or disk image design. On Mac OS X, you can either use a .dylib or you can use a .framework. The first is a file, the second is a bundle. Similarly for binaries, you can either have a regular exe or you can have an application bundle. Same end result... So it's more of a file layout issue, than different content. i.e. how to bundle libraries/headers and executable/data ? > I am under the impression that the dir structure of > wxLua-2.4.1-tiger.dmg is non-standard, but to me it looks a little bit > like a Framework and if we just move things around inside we can just > call it a framework. The disk image should match the source tarball, was the idea. I just added some pre-built Mac binaries and a folder icon... It doesn't really use Frameworks and it doesn't use Xcode IDE. (instead, it uses regular libraries/headers and ./configure) >> Both wxWidgets and wxLua could be made to use framework bundles >> instead, but so far it hasn't been worth the hassle of doing so >> (in addition, having it conform more to one specific platform >> doesn't really fit into the cross-platformness of wx - IMHO) >> >> Like >> http://wiki.gnustep.org/index.php/ >> User_FAQ#Why_not_use_framework_bundles.3F > > Well, I use the term Framework loosely, I guess I'm seeing it as a way > to package up a lot of files in a single dir in some semi-standard > way. That might be where the confusion lies, frameworks on Mac OS X are similar to "dynamic libraries" on other platforms and a system term. i.e. the content of a framework bundle follows strict guidelines, even though some are abusing/extending it (like Python and Java) > I don't know if we care that the binary wxLua packages are different > in MSW, Linux, and OSX? Ideally we have an installer for MSW (or just > a zip of *.exe, docs, and samples), Linux has rpms or debian/Ubuntu > packages, and OSX has ??? and that's what's unclear to me. For packages, Mac OS X comes with Installer.app and PKG packages - but it can also use just a zip of *.exe / *.dll like on Windows. For instance, my Code::Blocks package is just a .app in a .zip : http://developer.berlios.de/project/showfiles.php?group_id=5358 >>> Then add links from /$prefix/include, /$prefix/lib, and I guess >>> /Applications/wxLua.app to wxLua.framework/.../apps/wxLua.app. > > Like python does, these links are where we get Unix-like compatibility > from our Framework package. Well, Python only has semi-Unix-like compatibility - it still uses the "framework paths" for things like os and sys which causes a bunch of problems with software not expecting such Mac OS X paths... For instance, add-ons are installed in /Library/Python/2.5/site-packages --anders ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ wxlua-users mailing list wxlua-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxlua-users
