How to organize workspaces/projects on multiple platforms?
Posted: Mon Dec 07, 2015 7:15 pm
I am developing a multi-platform (*1) application, and was wondering how other people organize the project and workspace files in those cases (*2). I have CodeLite installed on both systems, compile on both (no cross-compiling), and am testing/running the program on both. I use GIT to keep the source code tree syncronized, and at the moment I have only the source and a few additional (platform independent) files in the repository, not the project files. Obviously, I need to have different project settings for each platform, but I want to have the project files in the repository as well, for history and to share between systems of the same type.
The possible solutions I have thought of so far are:
(for the examples, suppose my application is named "mystuff", with the project file "mystuff.project" and workspace file "mystuff.workspace")
- Keep the project files out of the repository (what I do now), and have a separate one on every platform.
- Keep one set of project files, but copy all the configurations (Debug, Release) for each platform, having Debug-linux, Debug-windows, etc., and make the default configurations invalid. The problem I see with this is, when I make a change and push/pull to/from the repository, the other platform will always have the wrong configuration preselected (can't avoid this, since the default configuration is saved in the one workspace file I have).
- Name the project per platform, "mystuff-linux.project", "mystuff-windows.project", etc. in the main project directory.
- Make different directories per platform just for the project files, and put the specific files there. The projects refer to the source files in the parent directory.
To be clear, this is not about the source code itself, GIT, or how to configure the projects specifically, I have all that working on both systems already, it's about how to organize the configurations on different platforms. I don't need help to solve a specific problem, I just wanted a discussion about what would make the most sense, pros and cons, and possibly with some reasoning behind it. Also, there might be a different solution to this that I haven't thought of yet.
I was also wondering if there is any other relevant stuff that I should have in the repository, except the *.project and *.workspace files. It looks to me that those are the only important files, everything else is generated, that seems to be connected to the workspace and project, and if at all it holds only layout information (like which files are opened in tabs, tab order etc.) and is not essential to have in the repository.
I am not doing this yet, but at some point I will also build installers for Windows and packages for Linux, and was wondering what the best practice is to store those in the repositories. Meaning I would have to store both the configurations to build the installers, and the installers themselves. Keeping this in mind, it seems the platform-specific directories are the best solution.
(*1) At the moment only Linux (2 different installations) and Windows, but I might extend this to more platforms in the future, and possibly different Linux distributions.
(*2) For convenience, I will only talk about "the project files", meaning this includes the workspace file(s) as well. It looks like there is very little relevant information in the workspace file anyhow. From what I can tell, only the included projects and the assigned and active configurations are stored there (not the configurations themselves, only the mapping of workspace to project configurations).
The possible solutions I have thought of so far are:
(for the examples, suppose my application is named "mystuff", with the project file "mystuff.project" and workspace file "mystuff.workspace")
- Keep the project files out of the repository (what I do now), and have a separate one on every platform.
- Keep one set of project files, but copy all the configurations (Debug, Release) for each platform, having Debug-linux, Debug-windows, etc., and make the default configurations invalid. The problem I see with this is, when I make a change and push/pull to/from the repository, the other platform will always have the wrong configuration preselected (can't avoid this, since the default configuration is saved in the one workspace file I have).
- Name the project per platform, "mystuff-linux.project", "mystuff-windows.project", etc. in the main project directory.
- Make different directories per platform just for the project files, and put the specific files there. The projects refer to the source files in the parent directory.
To be clear, this is not about the source code itself, GIT, or how to configure the projects specifically, I have all that working on both systems already, it's about how to organize the configurations on different platforms. I don't need help to solve a specific problem, I just wanted a discussion about what would make the most sense, pros and cons, and possibly with some reasoning behind it. Also, there might be a different solution to this that I haven't thought of yet.
I was also wondering if there is any other relevant stuff that I should have in the repository, except the *.project and *.workspace files. It looks to me that those are the only important files, everything else is generated, that seems to be connected to the workspace and project, and if at all it holds only layout information (like which files are opened in tabs, tab order etc.) and is not essential to have in the repository.
I am not doing this yet, but at some point I will also build installers for Windows and packages for Linux, and was wondering what the best practice is to store those in the repositories. Meaning I would have to store both the configurations to build the installers, and the installers themselves. Keeping this in mind, it seems the platform-specific directories are the best solution.
(*1) At the moment only Linux (2 different installations) and Windows, but I might extend this to more platforms in the future, and possibly different Linux distributions.
(*2) For convenience, I will only talk about "the project files", meaning this includes the workspace file(s) as well. It looks like there is very little relevant information in the workspace file anyhow. From what I can tell, only the included projects and the assigned and active configurations are stored there (not the configurations themselves, only the mapping of workspace to project configurations).