Author Topic: workspace on steroids  (Read 6543 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
workspace on steroids
« on: December 31, 2012, 07:10:26 pm »
In this topic I would like to gather requirements for more powerful workspaces in CB.
Feel free to add ideas as you like.
Later on we can prioritize them and make a roadmap.

Req 1 :
- ability to set compiler options, that will apply to all projects (and as such to any target in a project) in the workspace
- these settings need to persist ==> in foo.workspace file

Req 2 :
- ability to reload a project (now one has to close it and reopen it [that could be the implementation for a reload, but it is a bad one since the reloaded project will end up at the end in the project tree/workspace and not where it used to be)
- this is highly important if one wants to reload a project for the unitsglob feature

Req 3 :
- in the use cases where projects have similar targets (debug / release paradigm), it should be possible to set compiler options on the workspace level per target (so it will apply to all targets of the same name in all the projects in the workspace)
Note : the debug/release paradigm is use a lot, completely different to CB's own approach of a project containing targets which are actually subprojects, it might not be bad to have a clear distinction/switch that makes clear which paradigm one is using (to be seen if this is needed)

Req 4 :
- parallel build, now we have parallel build within a project/target, however keeping dependencies in mind, it might even be possible to build several projects in parallel [executable depends on lib a/ lib b /lib c ==> a, b, c could be build in parallel, and then within each lib a parallel build as we have today can occur]
- to be investigated if the dual layer of parallel build will not fight to much (but in 8+ cores this might be a speed up)


... more to add , just have something to start out with ....

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: workspace on steroids
« Reply #1 on: December 31, 2012, 07:28:45 pm »
Req 1 :
- ability to set compiler options, that will apply to all projects (and as such to any target in a project) in the workspace
- these settings need to persist ==> in foo.workspace file
Just derive cbWorkspace from the same base as cbProject.
Also it should be possible to make local changes not affecting the .workspace file.

Req 2 :
- ability to reload a project (now one has to close it and reopen it [that could be the implementation for a reload, but it is a bad one since the reloaded project will end up at the end in the project tree/workspace and not where it used to be)
- this is highly important if one wants to reload a project for the unitsglob feature
I think it is available in the code...
Why don't you provide a call which rebuilds the file list only, when unitsglob is used?

Req 3 :
- in the use cases where projects have similar targets (debug / release paradigm), it should be possible to set compiler options on the workspace level per target (so it will apply to all targets of the same name in all the projects in the workspace)
Note : the debug/release paradigm is use a lot, completely different to CB's own approach of a project containing targets which are actually subprojects, it might not be bad to have a clear distinction/switch that makes clear which paradigm one is using (to be seen if this is needed)
This sounds like something hard to do. Probably a checkbox could be added - "Modify targets".


Req 4 :
- parallel build, now we have parallel build within a project/target, however keeping dependencies in mind, it might even be possible to build several projects in parallel [executable depends on lib a/ lib b /lib c ==> a, b, c could be build in parallel, and then within each lib a parallel build as we have today can occur]
- to be investigated if the dual layer of parallel build will not fight to much (but in 8+ cores this might be a speed up)
This is separate feature requiring major rewrite of the process executor. Probably you can start a separate topic.
(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 killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5529
Re: workspace on steroids
« Reply #2 on: December 31, 2012, 08:29:10 pm »
point is to discuss first requirements, and not think in terms of implementations.   ;D

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: workspace on steroids
« Reply #3 on: December 31, 2012, 08:32:06 pm »
OK, but as I see it only req1 and req3 are related...
(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!]