Author Topic: Code::Blocks workspaces and source control  (Read 883 times)

Offline cacb

  • Regular
  • ***
  • Posts: 366
Code::Blocks workspaces and source control
« on: April 16, 2017, 01:43:21 pm »
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? 

Offline sodev

  • Multiple posting newcomer
  • *
  • Posts: 107
Re: Code::Blocks workspaces and source control
« Reply #1 on: April 16, 2017, 04:18:27 pm »
Your git-codeblocks already exists, its just called git submodule ;)

Offline cacb

  • Regular
  • ***
  • Posts: 366
Re: Code::Blocks workspaces and source control
« Reply #2 on: April 16, 2017, 04:56:48 pm »
Your git-codeblocks already exists, its just called git submodule ;)

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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10369
Re: Code::Blocks workspaces and source control
« Reply #3 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.
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cacb

  • Regular
  • ***
  • Posts: 366
Re: Code::Blocks workspaces and source control
« Reply #4 on: April 20, 2017, 04:41: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.

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.


Offline sodev

  • Multiple posting newcomer
  • *
  • Posts: 107
Re: Code::Blocks workspaces and source control
« Reply #5 on: April 20, 2017, 06:59:35 pm »
Use SVN then, there the same feature exists and is called External :). Its just one line in the externals property to pull in (a part of) another repository, much more easier than git (well, tbh i'm not using git for our own projects, i only checkout 3rd party projects, thats already complicated enough for me ;D). Want always the current revision? Pin it to HEAD (very bad idea, defeats the purpose of revision control, your old revisions magically change when the external repository updates which might/will break your perfect old revisions suddenly). Otherwise pin it to a specific revision. We are using this system for many years on quite a number of projects successfully.

But this is indeed beyond the scope of CodeBlocks, unless some day they decide to fully integrate support for all the important version control systems out there :).

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 10369
Re: Code::Blocks workspaces and source control
« Reply #6 on: April 20, 2017, 07:49:14 pm »
But this is indeed beyond the scope of CodeBlocks, unless some day they decide to fully integrate support for all the important version control systems out there :).
Why do you use the word "all" when talking about VCS? There is only one system out there, the others just are obsolete. :)
<debugger plugin maintainer>
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]