Bug - Fixed kolmafia 15.4 support for osx 10.4.1?

[cahavathra]

after mounting the .dmg file, the icon is blanked out and cannot be run, only giving the message "this application is not supported on this system." will simply changing the .jar file in the 15.3 update it normally, or are there any notable differences with running the app instead? Listed under bugs since assuming its supposed to run on osx 10.4.1.

 

[Veracity]

Huh.

Which "icon" - the .dmg? the .app in the .dmg?

This is the first time I've spun a release while running Lion. Perhaps the App Bundler has some parameters that need some tweaking.

In any case, running the .jar file should work just fine; you don't NEED a .app to run on OS X - any more than Windows users NEED a .exe file.

 

[cahavathra]

the .app in the .dmg wont run basically. but if the jar file will do, then sticking to that instead. Thanks!

 

[Veracity]

When you select the icon for the .app and do a "Get Info" on it, what does it say? What kind of Mac do you have? PPC or Intel?

 

[cahavathra]

I have a PPC, when I do a "get info" on it, it says "Application (Intel)".

 

[holatuwol]

I get the same error on my Mac, which is also PPC instead of Intel. I can confirm that when I package it myself, I can run it.

Which SVN revision was used for the actual release? I can repackage it and upload to Sourceforge?

 

[Veracity]

Version 11370 is "Bump version to 15.4". Thanks. Although ... if you generate something that is marked "Application (PPC)", then Lion users will not be able to run it, since Rosetta has been removed in Lion. Not that Rosetta is needed to execute a .jar file, but if the .app is marked PPC, I bet OS X will refuse to open it.

Considering that the .jar is architecture independent it seems silly that the .app is marked "Intel". There must be a jarbundler option to let you specify that. Hmm.

jvmarchs A space delimited string. Used to take advantage of 64-bit computing.
Example: jvmarchs="i386 x64_86 ppc"

lsArchitecturePriority A space delimited string. Contains an array of strings identifying the supported code architectures and their preferred execution priority.
Example: lsArchitecturePriority="i386 x64_86 ppc"

 

[holatuwol]

When I build it, it's marked as "Application (Universal)" so it should be okay. I'll go ahead and replace the dmg on Sourceforge.

 

[Veracity]

OK, the issue is that the JavaApplicationStub in Lion is Intel-only. This Mac OS X Hint talks about it.

Jarbundler lets you specify the Stub to include. In fact, since the default stub is only present if you are running OS X, we should include one, so that non OS X people can build a .app.

The Java Launching stub file is located inside of your application bundle in the subdirectory "Contents/MacOS/". The default name for this file is "JavaApplicationStub". It is used by the Mac OS X system read the applications plist and then launch the Java VM with the appropriate properties such as the classpath and main class name.

When run on OS X system, the JarBundler ANT task uses the current copy of the JavaApplicationStub from the developer's disk. Starting with JarBundler 1.8 the attribute stubfile can be used to set the name of the JavaApplicationStub file copied from the system framework. If the stub file referenced by the stubfile attribute exists, that file will be used along with it's filename.

When the JarBundler ANT task is used under Windows or Linux, a copy of the JavaApplicationStub must be supplied by the developer. This cannot be built from source but must be obtained from a Mac OS X system.

That note I linked to above says this:

Note that the JavaApplicationStub included in Lion is i386 and x86_64 ONLY, so if you somehow share app bundles with a PPC version of MacOS, this procedure will make the Java app no longer useable on PPC. There are Universal versions of JavaApplicationStub floating around, and it's possible to cook up your own using the lipo command, but the odds are if you're reading a Lion tip, that's the least of your worries.

We need a Universal version. Sounds like hola has one. I might have one from an older Java version.

Edit. Got one from my old system. I'll see about getting jarbundler to use it...

 

[Veracity]

Revision 11379 includes a fat version of JavaApplicationStub and makes jarbundler use it.

I tested by doing "ant jarbundler" and verifying that my .app was marked "Application (Universal)".

I'd be interested to hear if this also allows people on WIndows or Linux to successfully build an OS X .app

 

[Winterbay]

Revision 11379 includes a fat version of JavaApplicationStub and makes jarbundler use it.

I tested by doing "ant jarbundler" and verifying that my .app was marked "Application (Universal)".

I'd be interested to hear if this also allows people on WIndows or Linux to successfully build an OS X .app

That sounds like fun to try. What would I need to do to test it?

 

[Theraze]

Ran ant jarbundler, as you did, and got the following:

Buildfile: C:\kolmafia\build.xml

init:

compile:

svn-version:

gitsvn-version:

version:
[echo] Current revision: 11379M
[javac] Compiling 1 source file to C:\kolmafia\build

svn-version:

gitsvn-version:

unversion:

jar:
[jar] Updating jar: C:\kolmafia\dist\KoLmafia-15.4.jar
[jar] Warning: selected jar files include a META-INF/INDEX.LIST which will be replaced by a newly generated one.

jarbundler:
[null] Deleting directory C:\kolmafia\dist\KoLmafia-15.4.app
[jarbundler] Creating application bundle: C:\kolmafia\dist\KoLmafia-15.4.app

BUILD SUCCESSFUL
Total time: 10 seconds

Looks good as far as I can tell.

Not sure though... is the .app supposed to be a folder or a file? Because it's a folder on my copy...

 

[Veracity]

An app is a folder.

Thanks for trying it out! That's interesting, but it won't really be useful, since we package up the app into a disk image - a .dmg file - and THAT is done using "hdiutil", which is a Mac utility.