OSX 2712 - gnumake not found in bundle
Harry van der Wolf
I built a full 2712 bundle via Xcode with gnumake inside to enable
the huginstitchproject for mac users without Xcode and therefor
without gnumake on their system.
to fully test I did a "sudo mv /usr/bin/gnumake /usr/bin/gnumake.org".
In that case it fails to stich as it (obviously) cant find the
gnumake inside the bundle and falls back to the system version.
gnumake is inside Hugin.app/contents/resources/HuginStitchProject.app/
Contents/MacOS and works correctly when started by hand.
Next to this is an other error in the Xcode project which I cant
find. When compiling its start copying the enblend/enfuse/PT* and so
on into HuginStitchProject. The project is no longer copying from
<whatever>/hugin/mac/ExternalPrograms/repository/bin, but it is
copying from <whatever>/hugin/mac/../../ExternalPrograms/repository/
bin, so I had to create a softlink two directories higher to
ExternalPrograms (and your project points to Repository-dynamic, but
thats easily changed).
Harry
Harry van der Wolf
I forgot to mention that I don't know how to set the path variable
inside the Info.plist for HuginStitchProject
<key>LSEnvironment</key>
<dictionary>
<key>PATH</key>
<string>WHEREVER_MAKE_IS</string>
</dictionary>
I can't find a property key named PATH in the apple documentation. As
there are some "path like" property keys which all need to be set
relative to Resources. I tried ../MacOS, but that didn't function.
Harry
Op 28-jan-2008, om 12:43 heeft Harry van der Wolf het volgende
geschreven:
Ippei UKAI
On 2008-01-28, at 11:43, Harry van der Wolf wrote:
> I built a full 2712 bundle via Xcode with gnumake inside to enable
> the huginstitchproject for mac users without Xcode and therefor
> without gnumake on their system.
>
> to fully test I did a "sudo mv /usr/bin/gnumake /usr/bin/gnumake.org".
>
> In that case it fails to stich as it (obviously) cant find the
> gnumake inside the bundle and falls back to the system version.
>
> gnumake is inside Hugin.app/contents/resources/HuginStitchProject.app/
> Contents/MacOS and works correctly when started by hand.
I don't know what you are trying to do, but HuginStitchProject should
now search in-bundle "gnumake" with fall back to system "make".
> Next to this is an other error in the Xcode project which I cant
> find. When compiling its start copying the enblend/enfuse/PT* and so
> on into HuginStitchProject. The project is no longer copying from
> <whatever>/hugin/mac/ExternalPrograms/repository/bin, but it is
> copying from <whatever>/hugin/mac/../../ExternalPrograms/repository/
> bin, so I had to create a softlink two directories higher to
> ExternalPrograms (and your project points to Repository-dynamic, but
> thats easily changed).
I'll fix that. I must've forgotten to change the path back when I
added a new file.
On 2008-01-28, at 17:41, Harry van der Wolf wrote:
> I forgot to mention that I don't know how to set the path variable
> inside the Info.plist for HuginStitchProject
> <key>LSEnvironment</key>
> <dictionary>
> <key>PATH</key>
> <string>WHEREVER_MAKE_IS</string>
> </dictionary>
>
> I can't find a property key named PATH in the apple documentation. As
> there are some "path like" property keys which all need to be set
> relative to Resources. I tried ../MacOS, but that didn't function.
Please search for the documentation of LSEnvironment. It should have
the name-value pairs of environmental variable that the application
see. So PATH="/usr/bin" should be expressed PATH as the key and "/usr/
bin" as its value. It overwrites the user default in ~/.MacOS/
environment.plist or something. Note it's for the LS=Launch Services,
so if Hugin launched the child processes, they see the environment
variables that Hugin sees.
Ippei
--
->> 鵜飼 一平 (UKAI Ippei) ->>>>>>>>>>>>>>>>>>>>>>>>
MSN & AIM: ippei...@mac.com Skype: ippei_ukai
Homepage: http://homepage.mac.com/ippei_ukai/
Harry van der Wolf
Op 28-jan-2008, om 21:23 heeft Ippei UKAI het volgende geschreven:
>
>
> On 2008-01-28, at 11:43, Harry van der Wolf wrote:
>> I built a full 2712 bundle via Xcode with gnumake inside to enable
>> the huginstitchproject for mac users without Xcode and therefor
>> without gnumake on their system.
>>
>> to fully test I did a "sudo mv /usr/bin/gnumake /usr/bin/
>> gnumake.org".
>>
>> In that case it fails to stich as it (obviously) cant find the
>> gnumake inside the bundle and falls back to the system version.
>>
>> gnumake is inside Hugin.app/contents/resources/
>> HuginStitchProject.app/
>> Contents/MacOS and works correctly when started by hand.
>
> I don't know what you are trying to do, but HuginStitchProject should
> now search in-bundle "gnumake" with fall back to system "make".
>
I compiled the project straight ahead, which put gnumake into the
HuginStitchProject.app/Contents/MacOS.
As said, I moved the /usr/bin/gnumake out of the way to make sure it
would pick the internal bundle version or fail (if it couldn't find
it). Unfortunately it failed.
When that didn't work I started trying all kind of things.
>
> On 2008-01-28, at 17:41, Harry van der Wolf wrote:
>> I forgot to mention that I don't know how to set the path variable
>> inside the Info.plist for HuginStitchProject
>> <key>LSEnvironment</key>
>> <dictionary>
>> <key>PATH</key>
>> <string>WHEREVER_MAKE_IS</string>
>> </dictionary>
>>
>> I can't find a property key named PATH in the apple documentation. As
>> there are some "path like" property keys which all need to be set
>> relative to Resources. I tried ../MacOS, but that didn't function.
>
> Please search for the documentation of LSEnvironment. It should have
> the name-value pairs of environmental variable that the application
> see. So PATH="/usr/bin" should be expressed PATH as the key and "/usr/
> bin" as its value. It overwrites the user default in ~/.MacOS/
> environment.plist or something. Note it's for the LS=Launch Services,
> so if Hugin launched the child processes, they see the environment
> variables that Hugin sees.
>
I know what you mean, but the PATH as such is not available as key.
When you create installers there are a couple of path like settings
related to functions for an installer (source path, destination path
and these kind of things).
That's why I asked. Maybe you had some "trick" to do that for an
application. You can modify the environment.plist in your home
directory to add PATH statements to it and so on, but that's not
really helping here.
I'll try a complete clean re-run tomorrow.
Hoi,
Harry
Ippei UKAI
On 2008-01-28, at 21:46, Harry van der Wolf wrote:
> Op 28-jan-2008, om 21:23 heeft Ippei UKAI het volgende geschreven:
>> On 2008-01-28, at 11:43, Harry van der Wolf wrote:
>>> I built a full 2712 bundle via Xcode with gnumake inside to enable
>>> the huginstitchproject for mac users without Xcode and therefor
>>> without gnumake on their system.
>>>
>>> to fully test I did a "sudo mv /usr/bin/gnumake /usr/bin/
>>> gnumake.org".
>>>
>>> In that case it fails to stich as it (obviously) cant find the
>>> gnumake inside the bundle and falls back to the system version.
>>>
>>> gnumake is inside Hugin.app/contents/resources/
>>> HuginStitchProject.app/
>>> Contents/MacOS and works correctly when started by hand.
>>
>> I don't know what you are trying to do, but HuginStitchProject should
>> now search in-bundle "gnumake" with fall back to system "make".
>>
> I compiled the project straight ahead, which put gnumake into the
> HuginStitchProject.app/Contents/MacOS.
> As said, I moved the /usr/bin/gnumake out of the way to make sure it
> would pick the internal bundle version or fail (if it couldn't find
> it). Unfortunately it failed.
Right, now I can verify that it's not using the gnumake found in the
bundle. (A bit nicer trick would be: export PATH=""; ./
HugitchProject.app/Contents/MacOS/HuginStitchProject)
I thought it's okay as it finds the gnumake but I can see the code
actually builds the command line nicely but later do not use that
one. I'm not gonna touch it now as Pablo's doing something with
hugin_stich_project.
The keys and values look alright to me. Maybe something wrong with my
tags. I don't remember plist tags by heart. Anyway, changing the
LSEnvironment is just a classic hacking technique. I didn't try it by
myself for this, but I've used it once long time ago to get something
linked to a dylib in a different location.
Harry van der Wolf
> The keys and values look alright to me. Maybe something wrong with my
> tags. I don't remember plist tags by heart. Anyway, changing the
> LSEnvironment is just a classic hacking technique. I didn't try it by
> myself for this, but I've used it once long time ago to get something
> linked to a dylib in a different location.
>
>
> Yes, for dylibs, fonts and frameworks you can use it. I also did
> that myself. It does not work however with the PATH itself.
Ippei UKAI
Out of curiosity, I just checked if it works. It worked as intended:
copied HuginStitchProject.app and added LSEnvironment with PATH="".
Sure it stopped working.
The trick might be that those values can be cached by the launch
services. I've seen a behaviour suggests that when experimenting with
LSUIElement value. If you just change the value inside an existing
app, that might not work. Moving .app package to desktop and move it
back would be sufficient enough to clear it.
Harry van der Wolf
Op 30-jan-2008, om 1:15 heeft Ippei UKAI het volgende geschreven:
>
>
> On 2008-01-29, at 06:48, Harry van der Wolf wrote:
>>> The keys and values look alright to me. Maybe something wrong
>>> with my
>>> tags. I don't remember plist tags by heart. Anyway, changing the
>>> LSEnvironment is just a classic hacking technique. I didn't try
>>> it by
>>> myself for this, but I've used it once long time ago to get
>>> something
>>> linked to a dylib in a different location.
>>
>>>
>> Yes, for dylibs, fonts and frameworks you can use it. I also did
>> that myself. It does not work however with the PATH itself.
>
> Out of curiosity, I just checked if it works. It worked as intended:
> copied HuginStitchProject.app and added LSEnvironment with PATH="".
> Sure it stopped working.
>
Please explain what you did. If it works, I go sit in a small corner
feeling ashamed about myself and afterwards I will publish a new
bundle with the gnumake functionality.