User forums > Using Code::Blocks
Problem using Project Dependencies, do they work in Code::Blocks?
cacb:
Allow me to explain a real problem I have in Code::Blocks wrt. handling dependencies between projects within one and the same workspace. I cannot get it to work properly on either Windows or Linux, and the behaviour is different on the two platforms, causing different problems.
My workspace consists of a number of static library projects, plus a few applications (both console and gui) sharing the libraries. You should also know that on Windows I use the VC2008 Express compiler/linker, and on Linux I obvioulsly use the GNU gcc compiler linker. Each project has 4 build targets
W32_Release : Windows release build target
W32_Debug : Windows debug build target
UX_Release : Linux release build target
UX_Debug : Linux release build target
To simplify things, assume that my workspace consists of 5 projects App1, App2, lib_a, lib_b, lib_c, where the App's are executables and the lib's are static libraries.
App1: depends on lib_a, lib_b, lib_c
App2: depends on lib_a, lib_b
These dependencies have been declared via "Project | Properties" for App1 and App2. In the "Project Settings" tab, there is a button "Project's dependencies" where I have checked the relevant libraries to define the dependencies. (obviously, I have also declared in the "Linker Settings" for the project that the same libraries are to be linked).
Problem1 (Windows)
* editing code in lib_b while active project is App1 and asking for Build of App1 causes compilation of the edited code in lib_b and build of lib_b.lib, but it does *not* cause relink of App1 as it claims "Target is up to date."
* Building App2 is similar, it is not relinked as it should be
This causes endless confusion, and right now the only work-around I have is to perform some insignificant editing of an App1 source file to force a relink of App1, or request a time-consuming Rebuild.
Problem2 (linux)
* exact same code & change as Problem1. In this case, the situation is quite opposite, but also very problematic. Editing code in lib_b and asking for Build (not rebuild) of App1 causes complete recompilation of all files in lib_a, lib_b, lib_c. Asking for build again, causes another complete recompilation of all files in lib_a, lib_b, lib_c, even though no source files files ave been altered in any way.
* Building App2 causes complete rebuild of lib_a, lib_b
This causes endless time-consuming recompilation of code.
If I rebuild everything on both platforms, the applications run as expected, so there is no problem in getting the code to work. The problem is to understand how inter-project dependencies are supposed to work in Code::Blocks so that
* modified code is recompiled when needed (this is ok)
* unmodified code is NOT recompiled when not needed (not ok on linux, see problem2)
* Applications linking (and depending on) static libraries are relinked when the static libraries are updated. We assume here the static library is in the same workspace as the application.
I hope this is clear enough (if, not ask!), and I am sure there is some misunderstanding on my part. I would therefore very much appreciate some help describing how I should go about declaring the dependencies properly.
Thanks. :D
stahta01:
See if External dependency is what you want.
http://forums.codeblocks.org/index.php/topic,14278.msg95969.html#msg95969
Tim S.
cacb:
--- Quote from: stahta01 on June 19, 2011, 05:14:49 pm ---See if External dependency is what you want.
http://forums.codeblocks.org/index.php/topic,14278.msg95969.html#msg95969
Tim S.
--- End quote ---
Thank you for replying. I have looked at this now and considered various ways of applying the proposed solution, but I still see some significant issues
First, I don't think it addresses "Problem2 (linux)" at all as I described it? Will adding more dependency info cause less code to be compiled? The problem there was that everything seemed to be compiled every time.
Second, I have tested (on Windows) if adding "external dependencies" might help with "Problem1 (Windows)", and to some degree it cures the problem by creating another:
I have now told Code::Blocks in 3 different ways that it is supposed to depend on and use the static libraries:
- in the linker settings, the libraries are mentioned (in proper order, suffix can be ignored)
- in the Project's dependencies, the library projects are checked
- in the Build target dependencies (names must be specified with full path, name and file suffix).
So for a project with 4 build targets, you must list the names of the libraries you depend on 2x4=8 times , plus check the libraries in the project dependencies. Is there really no easier way?
Also, editing the project file by hand offers little help in this, the syntax used for external dependencies is not very readable (CPDE_USR is an environment variable I use):
--- Code: ---<Option external_deps="$(CPDE_USR)/lib/lib_a.lib;$(CPDE_USR)/lib/lib_b.lib;" />
--- End code ---
This is in contrast to the linker specification syntax, which is easier to deal with
--- Code: ---<Add library="lib_a" />
<Add library="lib_b" />
--- End code ---
I understand that we talk about several different things here
1. which libraries should this project link against
2. which projects should compile before this project
3. which files should be checked to determine if a relink of this project is needed
Somehow I feel that #3, using the existing external dependency feature, in the general case requires too much of the Code::Blocks user. I would much rather have a check-box option (for example under "Project build options") that one would have to enable and which would have the following meaning:
--- Quote ---"External dependency for any library mentioned in the linker's library list is implied".
--- End quote ---
If you had such a feature and enabled it for a project, then any library in the linker list would become an external dependency. The effect is that maintenance of such project/workspaces would become much easier (and more user friendly) in my opinion.
In summary
- Problem1 really needs a simpler solution, as described.
- Problem2 is unsolved
Comments and further help much appreciated :D
oBFusCATed:
Problem2:
Check the modification times of your source file, if they are in the future you'll get this problem. Use 'touch' in combination with find and xargs to fix the times.
Problem1:
Unfortunately we can't solve this problem easily, because C::B supports many compilers and many OSes.
I suppose you can simplify the setup by using a script or provide a patch to C::B.
killerbot:
Hi,
I feel your pain. I agree the linking dependency is not easy to use, honestly it is a real hell (little exaggeration ;-) ).
And "Option external_deps" is a real hell. Specifying through the GUI is a big waste of time, and editing it manually in the cbp file in a text editor is also no fun. Believe me I do it a lot, every day I am wondering If I will bump into the line limit, if any ;-)
In my case I have 4 targets, 2 targets per compiler (debug + release), like your setup. So 4 times adding a new 'relative path' but with minor changes since, the place where that lib is generated is a bit different per target. But that you can solve by using macro variables (TARGET_NAME, PROJECT_NAME), then you just have to maintain 1 such ugly line and copy/paste it 3 times.
I think we should improve CB, that step 3, (target dependencies) is more or less deduced from step 1 (project dependencies). The dependency is not the same a linking to a library, for example linking to system libraries, ... , we don't build those, so no need to specify a link/build dependency. It is just using it to link.
nasty thingy : project dependencies is stored in the workspace, while target dependencies are specified in the project (cbp) file. Maybe, we can just specify a 'project' dependency in the cbp file, and automatically we try to deduce target dependencies from it ....
Navigation
[0] Message Index
[#] Next page
Go to full version