[ptx] Hugin 0.6 on OS X Crashing

[Ippei UKAI]

On 2006-08-04, at 00:19, JD Smith wrote:
> 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?

The "localised.sh" file in ./mac directory is called from Xcode as a  
custom build phase. You can modify the script so that it works both  
from Xcode and Makefile. It patches some resource files and  
distributes the contents of locale folders to .lproj folders of the  
language. (This was to workaround for the bug in default locale  
selection of wxMac, but MacOS's built-in locale selection does the  
better job after all.)


>>> 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.

Well, "monkeying" is not that bad. The thing is CVS being not a  
system to version control directory structures and it is far easier  
to maintain things if it is defined in a script file. I think the  
idea of committing the .app bundle came from a developer who did not  
know enough about the bundling on OSX so that it was easier to just  
commit the working copy he got.

mkdir $buildDir/HuginOSX.app
mkdir $buildDir/HuginOSX.app/Contents
mkdir $buildDir/HuginOSX.app/Contents/MacOS
mkdir $buildDir/HuginOSX.app/Contents/Resources
echo "APPLHgin" > $buildDir/HuginOSX.app/Contents/PkgInfo
cp $infoFile $buildDir/HuginOSX.app/Contents/Info.plist
cp -r $xrcDir $buildDir/HuginOSX.app/Contents/Resources
...
chmod ... # should be needed, but don't know how #

I don't know Makefile syntax, but in Shell script, a few lines like  
above can make a bundle structure easily. No need of the structure  
itself in CVS, is there?


>>> 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.

I thought Apple suggests dmg+DnD installation be the primary means if  
possible. If we bundle enblend in HuginOSX.app, DnD works perfectly.  
Installer package would be the solution if we have to separate them,  
as we can make users to read the each project's read me files and  
decide whether to install both.

Of course autopano-sift can be dealt in the same manner, but it has a  
very different stability issue. We should deal with it on a separate  
thread, but please note autopano-sift on Mac is like a chunk of hacks  
at the best. Shell scripts should not be used in this extent if one  
wants to support a product for end users after all. (I really mean it  
after dealing with crazy Matlab for Mac...)

I think command line tools (meaning nona, clens, etc.) should be  
distributed separately. The best is to distribute them through Fink  
(or possibly DarwinPorts, but Fink is more popular). They are for  
UNIX users and should have required very different attitudes from  
statically linking and archiving directly. Unfortunately my target  
has been always HuginOSX.app and other tools are compiled in the same  
process, and eventually attached as someone had requested long time ago.


>>> 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.

You mean I should disable the preferences for those paths if it  
should be in normal places or embedded?
(By the way, usual places on Mac are "Application Support" folders;  
adjacent is a bad idea as no one wants enblend in /Applications.)


> 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).

Let's see what the Project Managers have to say to this. I think it's  
OK to bundle enblend and autopano-sift ready to use IF we give enough  
notice to the end users that those are not part of Hugin Project and  
may have different terms-of-uses (though they happen to be all under  
GPL).


Ippei

--
  ->> 鵜飼 一平  (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
   MSN & AIM: ippei_ukai at mac.com  (Skype: ippei_ukai)
   Homepage:  http://homepage.mac.com/ippei_ukai/