User forums > Using Code::Blocks
Code::Blocks workspaces and source control
cacb:
This post is relates to Code::Blocks workspaces and source control for the projects contained.
I have been using Code::Blocks for a long time and I love the way projects may be organised into workspaces, with project dependencies etc. My workspace folder structure may look something like this (simplified):
root -+--- ws-demo : workspace folder
+--- libA : folder for library A
+--- libB : folder for library B
+--- programX : folder for application 'programX'
The ws-demo folder would then contain a Code::Blocks workspace file
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
<Workspace title="ws_demo">
<Project filename="../libA/libA.cbp" />
<Project filename="../libB/libB.cbp" />
<Project filename="../programX/programX.cbp">
<Depends filename="../libA/libA.cbp" />
<Depends filename="../libB/libB.cbp" />
</Project>
</Workspace>
</CodeBlocks_workspace_file>
I.e. 'programX' is an application that depends on several libraries that may be general and reusable also in other contexts. The fact that in this example libA and libB appears in the workspace folder structure is just a convenience during development, it does not necessarily imply that they all belong to the same source control repository.
Let us further assume programX, libA, LibB exist in independent source control repositories created by other people, for example:
https::/github.com/user1/libA/
https::/github.com/user2/libB/
https::/github.com/myuser/programX/
To tie these together for my purpose, I could create a Code::Blocks workspace file and put that in its own repository:
https::/github.com/myuser/ws-demo/
Furthermore, it would be nice if the ws-demo.workspace file contained the above information, e.g. :
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
<Workspace title="ws_demo" url="https::/github.com/myuser/ws-demo/" >
<Project filename="../libA/libA.cbp" url="https::/github.com/user1/libA/" >
<Project filename="../libB/libB.cbp" url="https::/github.com/user2/libB/" >
<Project filename="../programX/programX.cbp" url="https::/github.com/myuser/programX/" >
<Depends filename="../libA/libA.cbp" />
<Depends filename="../libB/libB.cbp" />
</Project>
</Workspace>
</CodeBlocks_workspace_file>
On a fresh computer, I could do:
$ git clone https::/github.com/myuser/ws-demo/
cloning into 'ws-demo'...
$ cd ws-demo
Then I would run the hypothetical 'git-codeblocks' tool to collect all the projects in the workspace
$ git-codeblocks clone ws-demo.workspace
cloning into '../libA'...
cloning into '../libB'...
cloning into '../programX'...
Now everything is set up and I can go ahead and build.
$ codeblocks ws-demo.workspace
...build
The one thing that stops me from doing the above is that if the workspace file is edited in Code::Blocks, the "url" attributes would disappear since they are unknown to Code::Blocks. From the viewpoint of Code::Blocks, which may not want to deal with source control directly, the only thing required is to to maintain the "url" attributes, and not delete them.
The reason for bringing it up is because I have some workspaces like this and I would like to put each project in its own source control repository, but still use Code::Blocks workspaces like before without having to manually clone every project.
Obviously, one could store such info outside the codeblocks.workspace file, but XML is really made to handle such things.
What do you think of an idea like this?
sodev:
Your git-codeblocks already exists, its just called git submodule ;)
cacb:
--- Quote from: sodev on April 16, 2017, 04:18:27 pm ---Your git-codeblocks already exists, its just called git submodule ;)
--- End quote ---
Thank you for the tip. I read about it now and in some ways you are correct. However git submodules seems rather complicated, even the documentation says so directly. Maybe a setup like I described with a separate repository for the workspace + git submodules would work. I will give it some more thought.
I was thinking of something that would not necessarily be limited to git, but you do have a good point.
Thanks again.
oBFusCATed:
I don't see how the git-codeblocks solution will be any easier to use. And it will be pretty hard to maintain. The submodules feature of git is not easy to use or intuitive, but it works. Also it can it has the feature to select particular commit from the child repositories. Your proposal misses this feature.
cacb:
--- Quote from: oBFusCATed on April 18, 2017, 04:03:41 pm ---I don't see how the git-codeblocks solution will be any easier to use. And it will be pretty hard to maintain. The submodules feature of git is not easy to use or intuitive, but it works. Also it can it has the feature to select particular commit from the child repositories. Your proposal misses this feature.
--- End quote ---
The feature to select particular commit from the child repositories is powerful, but I would have preferred it to work in a different way by default. I think it would be more intuitive for it to by default selecting the latest child repository commit unless it was explicitly stated that it was bound to some other commit. So I am not sure I will use git submodules, especially if the child repository is likely to change frequently. Reading about submodules, there are too many answers on how to do various common things, it shows it is easy to get it wrong.
Anyway, this is a bit beside Code::Blocks, so I will not make this a long discussion. The way I see it now is that keeping Code::Blocks separate from the version control is generally a good idea. The main driver for asking the question was to find the most easy and intuitive way to handle Code::Blocks workspaces in a source control repository when (some of) the projects in the workspace are independent libraries you still want to be able to edit.
Navigation
[0] Message Index
[#] Next page
Go to full version