Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

workspace on steroids

(1/1)

killerbot:
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 ....

oBFusCATed:

--- Quote from: killerbot on December 31, 2012, 07:10:26 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

--- End quote ---
Just derive cbWorkspace from the same base as cbProject.
Also it should be possible to make local changes not affecting the .workspace file.


--- Quote from: killerbot on December 31, 2012, 07:10:26 pm ---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

--- End quote ---
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?


--- Quote from: killerbot on December 31, 2012, 07:10:26 pm ---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)

--- End quote ---
This sounds like something hard to do. Probably a checkbox could be added - "Modify targets".



--- Quote from: killerbot on December 31, 2012, 07:10:26 pm ---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)

--- End quote ---
This is separate feature requiring major rewrite of the process executor. Probably you can start a separate topic.

killerbot:
point is to discuss first requirements, and not think in terms of implementations.   ;D

oBFusCATed:
OK, but as I see it only req1 and req3 are related...

Navigation

[0] Message Index