User forums > Using Code::Blocks
Customizing Project Setup Wizards
imallett:
--- Quote from: stahta01 on February 14, 2014, 09:15:42 pm ---Then create a project template and use it.
--- End quote ---
Excellent; this was exactly what I needed to set up the build configurations/targets the way I needed. Suffers from the problem of not having centralized settings for all workspaces, but I think it's acceptable for now. Thanks.
Still don't know how to do inter-workspace dependencies, though. The only thing I could find were inter-project dependencies. I can understand if the build status of other workspaces cannot be managed, but I do need a way to add other workspaces' projects' include/lib paths--without adding them one-by-one for each workspace's project's target.
stahta01:
I hate the CB Project dependency (workspace based); you might like it.
This is under "Project" -> "Properties"
Tab "Project Settings"
Button "Project Dependency"
I like the external dependency much better.
This is under "Project" -> "Properties"
Tab "Build Target"
Button "Dependencies"
Tim S.
imallett:
--- Quote from: imallett on February 14, 2014, 09:40:44 pm ---Excellent; this was exactly what I needed to set up the build configurations/targets the way I needed. Suffers from the problem of not having centralized settings for all workspaces, but I think it's acceptable for now.
--- End quote ---
For some reason, for static libraries, it seems to add extra "lib" string(s) onto some of the targets' output filenames (so e.g. "libliblibmyproject.a"). This isn't in the template; maybe it happens during renaming.
--- Quote from: stahta01 on February 14, 2014, 09:50:21 pm ---I like the external dependency much better.
This is under "Project" -> "Properties"
Tab "Build Target"
Button "Dependencies"
--- End quote ---
What do I add here? I guess these correspond to this and this.
--- Quote from: stahta01 on February 14, 2014, 09:50:21 pm ---I hate the CB Project dependency (workspace based); you might like it.
--- End quote ---
I guess this is useful for forcing re-compile/re-link for dependent projects within one workspace? If so, I will use this for that purpose.
However, like I said, at this point I'm more concerned with adding correct includes and library paths. Under "Settings->Compiler->[Tab] Search Directories", I can change global compiler include and library paths. However, this isn't really appropriate for adding paths for user libraries. Also, there isn't a way to add a library to link against for each target (not that I'd necessarily want to link against every global library).
In the similar "Project build options" page, there is a similar per-project search directories, that I could make work, but it seems to me that doing this for each project doesn't scale--nor is it cross-platform without adding more targets for each platform.
stahta01:
NOTE: Your remarks about external dependency made no sense to me; this may mean they are wrong.
Sounds like you want a custom script to do what you want.
I am NOT really sure how to do those.
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.
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.
Tim S.
cacb:
--- Quote from: imallett on February 14, 2014, 11:21:42 pm ---However, like I said, at this point I'm more concerned with adding correct includes and library paths. Under "Settings->Compiler->[Tab] Search Directories", I can change global compiler include and library paths. However, this isn't really appropriate for adding paths for user libraries. Also, there isn't a way to add a library to link against for each target (not that I'd necessarily want to link against every global library).
--- End quote ---
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).
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 am a bit more fuzzy on external (inter-workspace) dependencies, so I shall not say to much. In my personal opinion, mentioning a library name in the list of libraries to link is a declaration that the current build target depends on that library, regardless of how or where the library is created (same C::B workspace, other C::B workspace, from 3rd party not using C::B). It may be that in reality things are not quite as transparent as this, but I do have several workspaces with projects referring to libraries not in the current workspace, and it seems to work fine.
Each of my projects includes a post-build step exporting include files, libraries and executables to a location different from the project itself. Dependent projects refer to include files and library files in that location via a global variable (or environment variable). I've made my own utility for this purpose as I think it simplifies managing multi-workspace development. I've also created my own utility for generating C::B project files using this scheme, and it seems to work ok (I'd be willing to share these utilities if anyone wants to include them in C::B, but I guess some work is to be expected).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version