You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is it really necessary to make a copy of the ChilliSource each new project?
Why not link to the source instead?
It reminds me a traumatic experience with cocos.
The reason it's like this is so that ChilliSource can be included as a git sub-module in your project. That has two benefits. First of all it's easy to keep the project up to date with the latest version of the engine. Secondly, if you need to hop back to a previous version of your project you don't need to keep track of which version of ChilliSource was used to build it.
This isn't made clear to a first time user however and it's a common complaint, so we're currently looking into alternatives.
I see but make changes to my fork, commit/push, update submodule and build the lib multiple times for each test project is a little tiring and each copy is more than 500 mb.
Should be great if CSProjectGenerator can take an parameter to link relative to the source and its build folder instead.
What I've done is make a config.py script which setup what path all the other scripts will take. I also configured the CS project to build on its project directory.
This way you can customize to point to any path or environment variable.
Also is easy to change it later and I think it's less to modify the CSProjectGenerator because the only thing that will dynamic change in the template is the that config.py.
Using config files like that comes with a number of issues of their own:
The config file becomes cumbersome to maintain if the project is being built on different machines - the more people there are on the project, the more difficult it is. This is especially the case if they're on different operating systems. The only viable way is to leave the config file un-versioned in source control and leave it to the user to manually maintain it for their local machine.
If the config file is un-versioned, then a project no longer builds out of the box.
As mentioned earlier if a user needs to go back to a previous version of their project, they'll have to manually keep track of which version of the engine was used to build it.
Config files are still being considered, but we're currently leaning towards a different approach. This would involve two different versions of the engine:
Installed version: An entry-level version of the engine which comes with an installer. This will set up a CS_PATH environment variable which is used by projects to locate the engine. The engine would be built to libraries and only contain the binaries for tools. This would be a smaller and easier to use version of the engine intended for beginners.
Source version: This would be pretty much as is, with the engine source contained inside the project - preferably as a git sub-module. This is much more convenient when configuring and adapting the source of the engine for a project. This would be intended for advanced users.
This is all still up for debate though, so we'll have to see how it turns out :)
You have some points.
Although the config file will not change the current behavior if the default configuration is point to the submodule folder.
I currently using an environment variable.
At the start my main issues is that the framework is setup to build in the project folder which prevents sharing the libraries and the scripts have hardcode or implicit path to the source.
The copy_windows_resources.py for example uses the project dir to link to the game source and the CS framework too.
It could take an explicit paramenter to the CS framework or use the config file shared for all the scripts.
Activity
Chilli-Ian commentedon Mar 22, 2015
Thank you for the feedback :)
The reason it's like this is so that ChilliSource can be included as a git sub-module in your project. That has two benefits. First of all it's easy to keep the project up to date with the latest version of the engine. Secondly, if you need to hop back to a previous version of your project you don't need to keep track of which version of ChilliSource was used to build it.
This isn't made clear to a first time user however and it's a common complaint, so we're currently looking into alternatives.
hammeron-art commentedon Mar 22, 2015
I see but make changes to my fork, commit/push, update submodule and build the lib multiple times for each test project is a little tiring and each copy is more than 500 mb.
Should be great if CSProjectGenerator can take an parameter to link relative to the source and its build folder instead.
hammeron-art commentedon Mar 23, 2015
What I've done is make a config.py script which setup what path all the other scripts will take. I also configured the CS project to build on its project directory.
This way you can customize to point to any path or environment variable.
Also is easy to change it later and I think it's less to modify the CSProjectGenerator because the only thing that will dynamic change in the template is the that config.py.
Chilli-Ian commentedon Mar 23, 2015
Using config files like that comes with a number of issues of their own:
Config files are still being considered, but we're currently leaning towards a different approach. This would involve two different versions of the engine:
This is all still up for debate though, so we'll have to see how it turns out :)
hammeron-art commentedon Mar 25, 2015
You have some points.
Although the config file will not change the current behavior if the default configuration is point to the submodule folder.
I currently using an environment variable.
At the start my main issues is that the framework is setup to build in the project folder which prevents sharing the libraries and the scripts have hardcode or implicit path to the source.
The copy_windows_resources.py for example uses the project dir to link to the game source and the CS framework too.
It could take an explicit paramenter to the CS framework or use the config file shared for all the scripts.