Extending Monkey, building native libraries
Monkey Archive Forums/Monkey Discussion/Extending Monkey, building native libraries
| ||
| It seems Monkey isn't THAT extendable just yet. Say if I was creating a library (think 3D libraries) for each target (or most of them), and I was to want the lib to compile or link during the build stage, I don't see any clean way of doing this just yet. Most monkey build/link functions seem hard-coded into TRANS or are copied from the TARGET monkey folder. It'd be helpful to get a way to add custom build files within a module folder itself, rather than trying to place everything within the TARGET folders. Does this make sense? It's a complicated procedure, but I think monkey will need this in the future (think 3D libraries). Anyone have any work-arounds, or if not, then I'll have to sit and wait or create new TRANS mods myself. |
| ||
| I'm using GLEW to support my multiple renderbuffers and render to texture functions on GLFW. In order to do this I have to change the base target project code, which effectively means that I'm running a branch of the monkey distribution. As you say, this isn't quite as extensible as it could be. |
| ||
| Hi, I've been thinking about ways to import object/library/class files etc into an app (ala bmx style Import "mylib.a"), and the big sticking point is with iOS. With all other targets, I can modify the target project files (eg: msvc project file etc) relatively easily, as they are either in text/xml format, or I just need to copy the import to a 'src' folder somewhere. But with iOS, xcode project files appear to be serialized binary, so it's virtually impossible to programatically 'add' files to the project for compilation/linking etc. Moving to command-line style 'makefiles' would fix this (although it'd be a total PITA), but then editing projects in xcode would become trickier as you'd need to keep xcodeproj/makefile in sync. All in all, it's not something I'm ready to attempt right now. Another approach would be to allow for custom targets in the targets dir - ie: additional targets that use the same underlying build process. So, you might add a 'glfw_minib3d' target to TARGETS, that uses the same build process inside trans as plain glfw does, but includes your own custom libs etc - kind of like a 'pre-tweaked' target project. The drawback here of course is that you can't 'mix and match' libs - they need to be pre-baked into a monolithic custom target. Such targets would also show up in the IDE, get copied to .build for additional tweaking etc - ie: they'd just be normal targets. To redistribute/install, users would just have to unzip into the targets dir. |
| ||
| dont know if this helps: http://stackoverflow.com/questions/1452707/library-to-read-write-pbxproj-xcodeproj-files |
| ||
| Such targets would also show up in the IDE, get copied to .build for additional tweaking etc - ie: they'd just be normal targets. To redistribute/install, users would just have to unzip into the targets dir. I would kill for this. This would allow us to create wonderful things such as (just thinking) a Swing target for desktop programing?If this happens, we would be able to create Jungle Ide Plugin target :D (among other nice things). |
| ||
| http://blog.octo.com/en/automating-over-the-air-deployment-for-iphone/ http://stackoverflow.com/questions/2664885/xcode-build-and-archive-from-command-line And then you could perhaps(?) add multiple targets, if the other libraries were created as a cross-target xcode project. http://stackoverflow.com/questions/3160787/targeting-multiple-platforms-in-iphone-sdk-4 Haven't tried it yet. |
| ||
| deleted. |
| ||
| I got it. I know how to do this with xcodebuild. I need a break now. whew. OK, here's how I did it, using minib3d as an example. - make a minib3d module - make an xcode project for minib3d and target is a static lib (bsd). this all goes in the module folder. - add to the "xcodebuilder" command line: xcodebuild -project MonkeyGame.xcodeproj -configuration Debug -alltargets OTHER_LDFLAGS="/Monkey/modules/minib3d/build/Debug/libminib3d.a" - xcodebuilder uses environment variables, and "OTHER_LDFLAGS" is one of them. It's documented in the Apple xcodebuilder reference guide to use it for linker files. To use, just add the settings AFTER the xcodebuild command line. Let me know how this works, but I feel with this Monkey should be able to use Modules appropriately. |
   |