Monkey Custom Targets: a possible solution
Monkey Targets Forums/User Targets/Monkey Custom Targets: a possible solution
| ||
| I feel that Monkey users must have easy access to custom targets, or Monkey will remain limited and stagnate. So here is my proposed solution: the "Custom Target" Target The only way this will work is if the community AND BlitzResearchLabs buys into this change and it becomes a part of Monkey. The selling point is that it is a separate target, and NO CHANGES are made to the Monkey compiler. What is it? Basically, it's a target that runs another transcc. See source code below. For the average user, the Custom Target is located in Ted's dropdown menu as just another target (I called mine "zCustom Target" to appear at the end of the list, but this can be changed easily.) When the user selects this target, the Transcc will only search for two preprocessor commands: #CUSTOM_TARGET #CUSTOM_TRANSCC the target is the name of the custom target, and the transcc is the path to the transcc executable to use (absolute or relative path). these preprocessor statements can be placed anywhere, including behind-the-scenes by the target maintainer. The user need only to setup (drag-n-drop) the proper files to the target folder. BEHIND THE SCENES ----------------- Some work will have to be done by the target maintainer. Once the Custom Target target is in place by the user, the new target system needs: - a new transcc - a new 'target' folder containing the new target structure - any supporting modules in the modules paths The way it works is that when the Custom Target is executed, it looks for the preprocessor variables in either the source file or the first pass of imports: #CUSTOM_TRANSCC="targets/wxmonkey/bin" #CUSTOM_TARGET="wxmonkey" where "wxmonkey" is a folder in targets, which contains the "builder" folder that houses the custom transcc. to compile GLFW the normal way, it would be: #CUSTOM_TRANSCC="bin" ''or c:/Monkey/bin #CUSTOM_TARGET="Glfw_Game" Therefore, the target maintainer must create a trans for each (if desired): transcc_winnt transcc_macos transcc_linux these transcc executables should be built with the appropriate target "builder", or it will not catch the new target option, unless the maintainer completely overhauls transcc. since these trans are kept separate, it does not matter as much what actions they take. they remain separate to normal monkey compiling. the entire target package could be kept in a single drag-n-drop folder if so desired, as long as the modified transcc directs "target" searches to the new folder location. The new target folder structure is: +Monkey ++targets +++wxmonkey ++++bin <- or whatever, the is the #CUSTOM_TRANSCC path ++++-transcc_winnt ++++-transcc_macos ++++-transcc_linux ++++targets <- this is repeated to mimic the search structure trans uses +++++wxmonkey +++++-TARGET.MONKEY ++++++modules ++++++template this can be changed, again, by customizing the new transcc. IS IT FOOLPROOF? --------------- no way. there were a couple hacks i had to add in, and some of this relies on the folder structure, but should be dynamic enough for most cases. |
| ||
| source code for Custom Target "builder": customtarget.monkey and the target folder is just "customtarget" with the TARGET.MONKEY file: #TARGET_NAME="zCustom Target" #TARGET_SYSTEM="customtarget" #TARGET_BUILDER="customtarget" there are no other files since the "Custom Target" target only pre-processes, no parsing. It passes all command options to the next transcc. |
| ||
| I know it's a lot, perhaps I should just present this to BRL, but I wanted to get some feedback/opinions/questions/concerns from other custom target makers first. thanks for your time. |
| ||
| I definitely agree it would be nice to have something like this. There is one gotcha which would need to be addressed; native files for core modules. At the moment a target needs to come with files that copy over the top of monkey core stuff, if it wants to play with monkey modules... There needs to be a way in which a target has the ability to add code/files to existing modules. For example: Target ABC needs to add the file mojo.abc.abc into modules/mojo/native otherwise the custom target will complain that even the most basic functionality of a monkey game wont compile. Unless this is possible at the moment? I couldn't find any info/documentation about it? It would be good if we could add something like: #TARGET_FILE_OVERRIDE="mojo.abc;modules/mojo/native/mojo.abc.abc" #TARGET_FILE_OVERRIDE="blah.abc;modules/blah/native/blah.abc" Each TARGET_FILE_OVERRIDE works in pairs so value1 is the local file and value2 is the path it should be copied upon project build. Or something along those lines? |
| ||
| Ow about embedding Lua into trans, each target is a script that calls trans to do the heavy lifting type stuff like translating, copying folders.. |
| ||
| There is one gotcha which would need to be addressed; native files for core modules. the new target system addresses some of this. see "monkey/targets/glfw/modules" for an example (V67 or above). some native files can be kept with the target. exceptions would be Mojo alterations. Ow about embedding Lua into trans, each target is a script that calls trans to do the heavy lifting type stuff like translating, copying folders.. i thought about scripting (in monkey no less!), but this would not allow for a target like wxMonkey which needs to add in function pointers to the language. Plus, copying folders and interesting things can already be done in custom targets. |
| ||
| I'm happy to be your Lua code monkey :-) I've done heaps of it with World of Warcraft addons. |
| ||
| This is honestly the way that I have always envisioned the target system. This would also make it easier for experienced coders just coming into Monkey that want to work on a custom target. There wouldn't be the need to mess with all of the underpinning, they could just download and install a target. |
| ||
| why wouldnt scripting allow function pointers to be added, trans only manipulates strings,copies files and executes o.s. commands |
| ||
| why wouldnt scripting allow function pointers to be added, OK, technically you can, but it'd be a lot of work. adding new commands to monkey's trans requires extending the cpptranslator class, and attaching to the execution. you could inject a script function there, but you'd have to expose all the classes and functions that trans uses to the scripting language. |
| ||
| the new target system addresses some of this. see "monkey/targets/glfw/modules" for an example (V67 or above). some native files can be kept with the target. exceptions would be Mojo alterations. Well yeah I saw this when working on the monkeymax target. This doesn't address the problem, this appears to be code only for bits imported by the target itself. If I wanted to allow a target to be compatible with existing modules I have no way of getting this to work. A module could be expecting to import a target specific file from its own file structure. We don't currently have a way to facilitate this with the target system. |
| ||
| A module could be expecting to import a target specific file from its own file structure. We don't currently have a way to facilitate this with the target system. Right, good point. Using a Custom Trans it can disguise itself as anything. This is what I use for the wxMonkey custom trans to use Mojo. TARGET.MONKEY: #TARGET_NAME="wxmonkey" #TARGET_SYSTEM="glfw" #TARGET_BUILDER="wxmonkey" |
| ||
| AdamRedwoods, do you think this would be suitable for the Ouya target? http://monkeycoder.co.nz/Community/posts.php?topic=4760 |
| ||
| yes, unless BRL is considering an official Ouya target. |
| ||
| one thought about this solution is that someone still has to compile the transcc every time there is a monkey update, if you want to use the latest updates within your target. i wonder if there's a way to make a shared lib for the transcc. |
   |