[Openmcl-devel] Codesigning a CCL based applicaiton

[Michael Minerva]

It seems that with your help I am getting very close!

On Aug 29, 2012, at 1:15 PM, R. Matthew Emerson wrote:

> 
> On Aug 29, 2012, at 3:04 PM, Michael Minerva <minerva at agentsheets.com> wrote:
> 
>> I am still just a little confused about what I need to do.  It seems from your script (and from my interpretation of your message) that I need to: goto the lisp kernel directory and do a make clean, copy all of the files from ccl into MyApp.app/Contents/Resources/ccl, then finally execute the codesign command.   Does this sound about right?
> 
> You may not need to copy all of them, but yes, you put the files you want in that directory, and then sign the bundle.
> 
>> 
>> I tried doing that but still get the same error.
> 
> If you get the same error, then I assume that you must still be trying to sign a heap image with a prepended kernel.  When you call save-application, make sure that you do *not* specify :prepend-kernel t.  If MyApp.app/Contents/MacOS/MyApp is larger than about 400K, then you've probably got a heap image in there.
> 

You were correct.  We build our application with a call to build-application which in turn calls save-applicaiton with :prepend-kernel t.  In order to try and get around this I have overridden build-application with an exact copy of the function except that it sets :prepend-kernel nil.  After executing this version and building again it created an application that no longer registered the error I reported when I would call the codesign command.  Awesome, thanks!

Now that bad news, the application is no longer executable, I suppose this was not to surprising since I had not done anything to add the heap image.  Next I went ahead and copied all the applicable ccl files into MyApp.app/Contents/Resources/ccl/ including dx86cl64.image.  This still did not work but I figured this was likely because of your next point about the names matching so I tried both changing the name of the image to MyApp.image (leaving the kernel as MyApp) and also tried changing the kernel dx86cl64 (leaving the heap image as dx86cl64.image).  Still none of these solved the problem.  

Now after trying all this I noticed that the file located inside MyApp.app/Contents/MacOS was not am executable file (it was a document and would open the binary in a text editor if I double clicked it), it now seems that this may be my main source of trouble.  

In order to try and simplify the process I decided to use the CurrencyConverter example (located in ccl/examples/cocoa/currency-converter), so I went ahead and followed the examples except instead of calling (require "build-application") I would execute my own version of build-application which has :prepend-kernel nil.  Now when I built this application I noticed that once again /CurrencyConverter.app/Contents/MacOS/CurrencyConverter was a document not an executable (btw in this case, the file inside MacOS was 39.6MB even though prepend-kernel was nil).  Also, the app would never load even after I added the ccl directory inside MyApp.app/Contents/Resources including the heap image.  Next I decided to go through the currency converter example as advised in the HowTo (calling  (require "build-application") instead of the build-application with :prepend-kernel nil) and this time it created an executable inside /CurrencyConverter.app/Contents/MacOS, and it was 40.1MB instead of 39.6MB.  

So this all begs a couple questions: first, should the file created inside MyApp.app/Contents/MacOS really be 400k (even if I have loaded lots of other lisp code before executing the build-application).  Second, do you know what I am doing wrong when building the currency converter with :prepend-kernel nil that could lead to the situation I describe?

Sorry to keep bothering you about this but I don't know of anywhere this is all documented.  

Thank again for your time!

--Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20120829/50bf9660/attachment.htm>