Cloud Compiling
Monkey Archive Forums/Monkey Discussion/Cloud Compiling
| ||
| One of the things I find annoying in Monkey is building for multiple devices. One idea would be to develop a Coud Compiling system, where the source and data files were send to a server, compiled for the target you want and then the compiled one sent back. This could nicely work with the subscription model to pay fro the service. |
| ||
| At least one person has done this for HTML5 builds, but not commercialized it. Very obvious that it would make money. One click rebuild and optionally upload to stores with my project settings and output needs to all targets at once? Yes, please. |
| ||
| Well that sounds like an external tool without the need of Monkey. Should be doable. |
| ||
| If IIRC Mark did an example with Monkey some years ago. Of course the target was only HTML5 at the time. I dont' know if there are legal issues or not. BRL could offert this as paid service... I posted the idea some days ago on Blitzbasic forum ([a]http://www.blitzmax.com/Community/editpost.php?post=1225026[/a]) |
| ||
| If IIRC Mark did an example with Monkey some years ago. Of course the target was only HTML5 at the time. I dont' know if there are legal issues or not. BRL could offert this as paid service... I posted the idea some days ago on Blitzbasic forum ([a http://www.blitzmax.com/Community/editpost.php?post=1225026]) |
| ||
| I've done it for HTML5, but not for public use yet... I'm planning to rework it a little before I try making it public (to see what disasters that brings on), but I do actually plan to mess with it again tonight. I have an Ubuntu/Linode-based backend server that receives Monkey code sent from my 'public' site via a form; the backend server builds it and sends only main.js back to the public site, which then injects it into a frame (on the public site). The public site holds a 'standard' set of sprites (which the backend server has a copy of), hence I don't have to send the entire project back to the public site. Works really well! I haven't tried building for any other platform, though -- I couldn't easily build for Windows/Mac/iDevice on the Ubuntu server, for example. |
| ||
| That is cool :) Would it work with data & content updates as well? This for Mac would be a dream for me since I'm almost only using PC. How difficult a project is this for something like iOS? I'm happy to install stuff on the Mac, have it act as a server, I just want to reduce the file copy mayhem and xcode trouble that usually happens - especially for testing a new version :) I thought the scope of a project like this was quite big, if only for Mac/iOS compilation? |
| ||
| I think you might have misread my last sentence, Tibit -- "I couldn't easily build for Windows/Mac/iDevice on the Ubuntu server"! My public site sends the source code to the backend server, where a PHP script creates a 'lock file' (to make sure it services only one request at a time) and a temporary build directory, copies in the data required (images in my case), builds the project for HTML5 and unlocks the lock file, ready to take the next request. Where my PHP script then sends back main.js, you could theoretically have it archive the temporary build folder (after building for your preferred target) and return that as a downloadable file. Of course, you could only build for the targets your server supports, so mine could only build for HTML5 and possibly Linux Desktop/C++ Tool (not sure about Android). How that would all work out in practise, though, I don't know! Adding content upload and management is really out of my comfort zone, too -- that's why I have a standard set of images at both ends, as it's meant to be for a tutorial site. I'm sure other targets could be done by someone with more talent/time/patience, but have only tried single-file HTML5 projects so far, which is all I need -- I've no experience at all of Mac/iDevice building in Monkey. (I did have some help on the public site part that submits/receives and injects the resulting Javascript, and that's the part I'm currently trying to figure out and rewrite in a way that I can comprehend.) I'll maybe try making it available at the weekend so I'm around to take it down if all goes wrong/site gets hacked/bandwidth goes nuts, etc! |
| ||
| Regarding other targets: your backend has to be capable of building them. a "building farm script" isn't that hard to write: you won't need to do it webbased (client side), just build a correct api and voila... various tools can submit what is needed (including some kind of "projectHash") ... another api call is then kicking off the build process - result is a processToken/Hash/... Your clients (the software on your pc) can then check the state of the compilation process using the processToken. Why this token? Imagine the compilation being delayed (others are building now ... so you are in a queue). The only thing you might get returned by sending the "startCompile"-command: if the source has some syntax errors in it (fast and dirty checks). So the really hard thing is to get it compile things for different targets: your server could do it "virtually" (kicking off virtual machines, remotely starting the compiler in the vm, copying files to the backend storage and pausing/stopping the vm). If your server is a "mac" I think you will have the best chances to compile for the rest (crosscompiling) but as apple has some problems with others being able to compile for mac ... this is a target which wont work. So again in short: - backend must enable compilation to the different targets (each must be setup'd) - backend needs a nice api - api: Assets (add, remove assets/data/source to specified projectToken, [optional: get]) - api: Project (add, remove, get) - - add: creates a new project, returns token - - remove: remove a project specified by token, removes contained assets/data/sources - - get: receive builds of the given projectToken from the specified targetID That "get" may return an queueToken (instead of the binary data) describing additional things: - api: Queue (add [admin], remove [admin], get) : get information about the current queue state of the given projectQueueToken You could add "publish" to api which does some magic (stores etc.) All in all: keep the api simple and clean (just google about REST-Services). If your api is working then, you can implement the interface using webbased approaches (php html css js) or platform specific (an win32/mac/linux binary). It depends on skills and time :D. Of course "api server" and "build server" can be on different computers (api server just informs build server about to-do-tasks). Also clients could check the api server, what ressources have to get uploaded/refreshed (md5 hashes should be enough): - api saves an md5 for each asset - clients compute md5 (webbased: check some md5-implementations in .js) and send out an status request to the api containing one or all hashes (api must be able to handle "single" or "group" data containers - see json style). api returns an array of "changed" ressource hashes/names - clients upload all changed ressources. There are plenty of possibilities - most of them should be "basically" codeable during a long weekend (server side + test code running on pure php locally). But of course this depends on the "build server" already being running (just add more and more targets afterwards). The "mac build" could be eg. deferred to some macs in the "buildMachines"-list (that is why a "queue" may be needed). bye Ron |
   |