Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicating source #5

Open
hammeron-art opened this issue Mar 22, 2015 · 5 comments
Open

Duplicating source #5

hammeron-art opened this issue Mar 22, 2015 · 5 comments

Comments

@hammeron-art
Copy link
Contributor

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.

@Chilli-Ian
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor

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 :)

@hammeron-art
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants