Jungle Ide compiler targets and solutions
Monkey Forums/Monkey Programming/Jungle Ide compiler targets and solutions
| ||
| I'm thinking that it would be a good idea to modify the current implementation of the target on solutions and projects, and make compiler configuration a single global option, instead of making it per-project. That is, instead of storing the compiler configuration for each project in a solution, it could be a global configuration. Is there many people having single solutions with different targets in the build process and using multiple-build options? The beneffit I see is that it would allow a simplification of the project file, as this information could be part of the solution user options, making it better for mercurial or git integration, and also, I considere that the workflow would be simplified in a way that you will no longer need to select a project (or project file) first, in order to modify the compiler options for that project, as they will be infered by the current global compiler configuration. This could also improve (just a bit) intellisense when target specific modules start to have target specific functionalities, as it would avoid Jungle Ide having to deal with several different internal databases at once, or having to filter a single big database for each intellisense request. Any options are welcome and information about use are welcome! |
| ||
| As I've requested the build configuration to be solution based rather than project based multiple times I'd be very, very happy to see this occur. I've never understood the use-case for per-project targets as a Monkey build only ever produces one output. I'd ask that you also consider adding the ability to call scripts/executables before/instead of/after the monkey compiler and also the ability to simply run the existing executable rather than rebuilding it. |
| ||
| I'd ask that you also consider adding the ability to call scripts/executables before/instead of/after the monkey compiler and also the ability to simply run the existing executable rather than rebuilding it. Yes, I'll be adding this too as I find it very usefull to package textures, etc before compilation. Just want to take one step each time, but I'll be implementing it, just not yet. I've never understood the use-case for per-project targets as a Monkey build only ever produces one output. It was/is an attempt to be ready for monkey generating dinamically linked libraries which would mean Monkey generating two separate outputs on a single compilation process. But I think the potential future gains are not worth it if we can get better usability. |
| ||
| Its not something that bothers me at all I do have some projects that I build for flash and some I build specifically for html5, and then others that I build for a few different targets. So if I understand what your talking about your going to simplify the files jungle makes to track its ide specific config options, I am happy the way it is to be honest, I just tell hg or svn to ignore the jungle files. would there be a major benefit from doing this ? from making your change ? other than reducing the number of files from what 3 or 4 it is now to less? |
| ||
| would there be a major benefit from doing this ? from making your change ? If you have single project solutions, it will be no difference. If you have solutions that have, let's say, an App and modules, you'll benefit from having a single build configuration for everything. That said, if you hapen to have a solution that produces several apps in the same build, and you're buiding each one for a different target, you'll have to compile separately. But I think that's a very unusual sceario, while the module(s)+app is much more common. |
| ||
| Ah I understand , it's not something that will really effect me anyway as my licence ran out and I don't have the cash to renew, with a little luck I should have some spare funds in a few months :/ until then I will stick with the version iv got now. I was wondering if you will be making a converter to handle old projects, for example the code I am working on now when I finally get a new licence will jungle be able to handle converting the old system to the new or will I at some point have to redo all my solutions. ? |
| ||
| it will be backwards compatible. not even a converter should be required. |
   |