NOTE: Your remarks about external dependency made no sense to me; this may mean they are wrong.
...
But, I still do NOT see the need for multiple workspace dependency; this might mean you do NOT understand CB workspaces or I do NOT understand what you are needing.
I have used Code::Blocks a little more. I now think they are just an arbitrary collection of projects, rather than something overarching (as a "solution" is in MSVC). Correct?
Sounds like you want a custom script to do what you want.
I am NOT really sure how to do those.
Actually, in the time since my last post, I wrote a Python build system. It essentially generates the project file in the manner I require, adding include directories, library directories, build configurations, compiler options, and so on. Really crufty, but super effective: my entire codebase compiles correctly now.
Also, you might wish to look at the nightly plugin "ProjectOptionsManipulator" it might be able to do what you want.
Another option is use premake to build "standard" CB Projects or cmake to build "custom makefile" CB Projects.
Note: premake and cmake are 3rd party project build tools.
I have used cmake, and it's . . . annoying to use. I haven't even tried generating project files from it. I haven't heretofore heard of premake, although it looks nice (better than cmake anyway).
Hi, I like your approach and stated goals (even though my own may be slighty different).
For managing paths, I presume you are aware of the global variables feature in Code::Blocks? In my opinion, this is one of the strongest features of the IDE, as it separates the project setup from the physical include and library paths. See Settings -> Global variables.... For example define a variable BOOST and then refer to it in project files using $(#BOOST.include) and $(#BOOST.lib). This also helps make your projects cross platform (mine are cross platform across Windows & Linux).
I thought I did, and then I reread your post. I will definitely have to do this. I was previously considering making separate targets for each platform, which is obviously terrible.
Notice also that compiler and linker settings can be defined on both project level and target level. As you have seen, you may define inter-project dependences within a workspace. When you have multiple build targets in multiple projects, my experience is (someone correct me if I am wrong) that it really means dependencies between build targets (using the same target name) in different projects. So your scenario involving Project I (library) and Project II (executable) seems satisfied.
I can't quite parse this. Most of the options are in fact specified on a project level, but I do have some things on a target level. The main thing is coming up with a clean way to make targets of one project
depend on the same targets of another. As above, the cleanest way I found to do this is to resolve all the dependencies in my Python script and then just write the project file from nothing accordingly.
I'll probably just be using the Python script for now. It does (or very shortly will do) what I need exactly, even if it isn't pretty. Maybe in the future I'll look into premake.
Thanks,