Project organization

Discuss the JavaScriptCore Objective-C wrapper/bridge
Post Reply
ddribin
Posts: 19
Joined: Mon May 12, 2008 9:21 am

Project organization

Post by ddribin » Mon May 19, 2008 5:05 pm

In the documentation, you recommend against including the source directly in your project. I disagree with this, as I often prefer including the source in my own project. I prefer not to have many private frameworks (for various reasons).

Also, for applications where frameworks are not possible (command line tool), it's easier to work with source directly, than a static library, if possible. Using Objective-C static libraries can be problematic if they contain categories. You are forced to use the -ObjC linker flag.

In any case, I'd like to see the source code structured so that including the source code into your own project is easier than it is. My suggestion would be to create a subdirectory for each target. So instead of just source/, I'd suggest:

* source/JSKore/
* source/Libraries/
* source/Utilites/
* source/jski/
* source/JSKurtle/

This way, one can easily copy which portions they need (i.e. only JSKore/).

-Dave

gandreas
Immortal
Posts: 1464
Joined: Wed Feb 04, 2004 6:02 pm
Contact:

Post by gandreas » Tue May 20, 2008 12:59 pm

The biggest reason against directly including the sources is that it prevents you from making projects that can be built using the 10.4u SDK. This is because the JavaScriptCore stuff lives in 10.5, but is also available on 10.4 with Safari 3.x, but is not in the 10.4u. By using a framework that is compiled against "current os" (instead of a specific SDK), which gets the appropriate version, hiding the problem from a project that uses 10.4u SDK.

That being said, I'm also running into problems with coded generated from my "bridgeSupport" converter. Since those files don't include any versioning info, I don't know if a bridged call that I'm generating code for exists on 10.4 or not - in a perfect world, the call shouldn't appear in the JavaScript world at all. Worse, this is going to require that compiling the generated code requires compiling on 10.5 (since there's no way to know how to generate the conditional code that would normally be done to prevent trying to access types that aren't on 10.4).

I wish I could just require compiling under 10.5, but that doesn't quite cut it for me personally (since I've got a 10.4 machine I use for testing, and not being able to make changes to the code during debugging is problematic).

And for the record, you need the -ObjC linker flag not just for categories, but also for any classes that are instantiated by "NSClassFromString()" (and probably a few other strange cases as well).

Cleaning up the source directory is pretty reasonable - I've gotten use to just seeing the files in Xcode (and not the raw directories) so I tend to forget what a pain it can be to access them directly. I'd probably add an extra layer of "Applications" that both jski and JSKurtle (and any other examples I may add) will live in.

Bringing this back to the whole "linking directly" I've yet to decide on what is the best way to handle "extensions". Taking a simple example of Quartz, I can generate bridging code to be able to call all the CG routines (subject to compile OS dependancies noted above), but the result is fairly large, and I'm not sure that it should be "forced" into everything, even if you don't use it. Worse, it may need to be "dynamically loaded" (say, from the command line interpreter) as well as "statically loaded" (since you may not want your app to load dynamic code, but do want to bridge Quartz calls).

I'm hoping to have this all resolved and another release before WWDC (more accurately, I'm hoping to have a beta of a developer utility that uses this available at WWDC), so any comments, suggestions, or complaints are welcomed (after all, making something perfect for me may make it unusable for others)!

ddribin
Posts: 19
Joined: Mon May 12, 2008 9:21 am

Post by ddribin » Fri May 23, 2008 1:22 am

gandreas wrote:Bringing this back to the whole "linking directly" I've yet to decide on what is the best way to handle "extensions". Taking a simple example of Quartz, I can generate bridging code to be able to call all the CG routines (subject to compile OS dependancies noted above), but the result is fairly large, and I'm not sure that it should be "forced" into everything, even if you don't use it. Worse, it may need to be "dynamically loaded" (say, from the command line interpreter) as well as "statically loaded" (since you may not want your app to load dynamic code, but do want to bridge Quartz calls).

I'm hoping to have this all resolved and another release before WWDC (more accurately, I'm hoping to have a beta of a developer utility that uses this available at WWDC), so any comments, suggestions, or complaints are welcomed (after all, making something perfect for me may make it unusable for others)!
Currently, I'm really only interested in the JSKore stuff. Simple KVC access to ObjC objects I pass in is more than enough bridging for my current project (I'm writing a templating engine).

I haven't really played with the extensions, much. So long as each extension could be included individually somehow (static lib or dynamic plugin), then it can be as lean as the end user wants.

-Dave

gandreas
Immortal
Posts: 1464
Joined: Wed Feb 04, 2004 6:02 pm
Contact:

Post by gandreas » Tue May 27, 2008 1:11 pm

ddribin wrote:
I haven't really played with the extensions, much. So long as each extension could be included individually somehow (static lib or dynamic plugin), then it can be as lean as the end user wants.
That is the goal exactly!

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests