[ptx] Hugin 0.6 on OS X Crashing

[JD Smith]

On Thu, 2006-08-03 at 23:24 +0100, Ippei UKAI wrote:
> On 2006-08-02, at 01:13, JD Smith wrote:
> >
> > Thanks, Ippei.  So a Makefile which creates the .app directory  
> > heirarchy, and copies components in from the mac/ source directory  
> > should be simple to code, yes?  There is no other patching, etc.  
> > which your XCode project does (other than gather all the needed  
> > libraries, and compile things statically).
> 
> Well, there might be a few compiler arguments (especially -D options  
> if ever set), but the basic process is simply compile->bundle.
> As I have written, some patches are applied to the resource files  
> when the "localised" script thingy (the name is no longer correct as  
> it does more than localising the resources) which is called in the  
> last step of Xcode build process.

I don't understand this.  This is an XCode specific localization task?
How would you implement it in a Makefile?  I'm not sure how this would
impact my suggested approach.  Can you list explicitly the steps you
take to build the current .app (scripts/XCode things (and command-line
equivalents if possible)/etc.).  Do we need to modify the resource
files, or can we come up with something that works on all platforms
equally well?

Just so everyone is clear, I'm suggesting a means by which a Hugin.app
application bundle could be built directly with "./configure; make;",
just like all other platforms (Windows too, I guess?).  This will allow
more people to develop in a cross platform way, and will hopefully also
permit people who want to use the XCode route to do so.  The best of
both worlds.  Obviously, you'd have to assemble and compile all the
dependencies (Vigra/etc.), but many (all?) of those are available
already, e.g. in darwinports.

> > Could you suggest any thing else the Makefile would have to do?   
> > For example, Emacs' configure.in does:

> .r files are not needed with wxWidgets 2.6. Many frameworks are to be  
> linked, but none of them are for hugin's main code. wx requires quite  
> a few and pano12 requires Carbon at least. I have no idea of  
> "carbon_appdir=/Applications" part, but it's best not to hard code  
> any paths like that ever in the build process.

That's just for "make install", to copy things to /Applications.  We can
implement that or not.

> > etc.  So I think it's really just a matter of:
> >
> > 1. creating and checking into CVS mac/Hugin.app with all the  
> > correct structure and handful of pre-existing files from your  
> > HuginOSX.app bundle.
> > 2. arranging for Pablo's configure/Makefile heirarchy to copy the  
> > binary into the correct location.
> 
> Please not to commit the directory structures in the CVS. It's better  
> be created in the build process for many reasons. The stupidest  
> reason is that Emacs.app has /CVS folders inside the app package and  
> looks stupid. The .plist file is in the CVS, and Package file is only  
> a matter of dumping 8 characters into a file.

The nice thing with a .app/ directory is everything is where it needs to
be without monkeying with the Makefile.  We could make a "Hugin.appsrc/"
and then rename that "Hugin.app", stripping out the CVS stuff while
copying, if this seems preferable.

> > 3. (optional) Borrow their make-package script to make a compressed  
> > installer package .dmg file.
> 
> Well, .dmg is just a disk image format. Probably a good idea to make  
> a lisence enabled dmg file for HuginOSX.app and a separate package  
> (proper Installer package or just .tgz file) to distribute command  
> line tools.

The .dmg contains a .pkg, which runs automatically in OSX's installer.
So it does everything for you.

> > We could even copy enblend and autopano-sift into Contents/MacOS  
> > (assuming license issues with the later don't interfere), and pre- 
> > configure Hugin to look for them there.
> 
> This is what I have intended to do and technically it's already  
> possible. Eventually it's not done for license and/or other moral  
> reasons. (Don't ask me...) I'm attaching AppleScript applications  
> that let users to do this by their selves. My enblend lives in /MacOS  
> and autopano-sift lives in /Resources/autopano-sift. With those files  
> inside the bundle, simple DnD installation is possible.

Yes, and as Roger pointed out, this is confusing for the end user.  We
should either stick to enblend and autopano-sift as separate, and have
them linked to in their normal place in the directory hierarchy
(adjacent Hugin.app, I guess), or just embed them.

I actually see no issue with embedding Enblend and autopano-sift into
Hugin.app, since both are GPL.  The patent issue is a separate one; I
believe it's still pending in the US, but even if it weren't, patent
infringement has nothing to do with copyright (for instance, it's
estimated that the Linux kernel infringes 300 or more patents).

JD