Author Topic: Problem using Project Dependencies, do they work in Code::Blocks?  (Read 10970 times)

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
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
« Last Edit: June 19, 2011, 04:28:24 pm by cacb »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #1 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.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #2 on: June 19, 2011, 07:28:50 pm »
See if External dependency is what you want.

http://forums.codeblocks.org/index.php/topic,14278.msg95969.html#msg95969

Tim S.


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;" />

This is in contrast to the linker specification syntax, which is easier to deal with
Code
<Add library="lib_a" />
<Add library="lib_b" />

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".

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
« Last Edit: June 19, 2011, 07:33:44 pm by cacb »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #3 on: June 19, 2011, 09:17:50 pm »
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.
(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: 5490
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #4 on: June 19, 2011, 10:10:32 pm »
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 ....

« Last Edit: June 19, 2011, 10:12:31 pm by killerbot »

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #5 on: June 19, 2011, 10:31:46 pm »
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.

Thank you for replying, but

Problem2: This is not a problem with source file times. I have checked, and every single source file is old. Only the files generated by Code::Blocks (such as *.depend) are new. No files are in the future. There is something else going on and it is rather annoying. It has been going on for some time, and that is why i post about it here. I usually try to solve my issues before asking. I will also check on another machine, to see if there is any different behaviour. Btw. I forgot to say I am using the nightly build 7215 from jens lody on Linux.

Problem1: I don't understand this answer, what I described is independent of the compiler and OS. Simply include an option to instruct Code::Blocks to treat the libraries the user has explicitely provided as input to the linker also as external dependencies. Code::Blocks knows which libraries I have entered (it is listed in the .cbp file). So it can treat them as dependencies if told to do so. I suppose I could become a C::B developer to do this.... however I think you get my point.


Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #6 on: June 19, 2011, 11:09:03 pm »
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 ....

Thank you, thank you for the moral support, I needed that!  :lol:

Some comments to what you are saying: Yes, step 3 is in many cases (not in every case) redundant if you include an option to say that input libraries (those given to the linker) are to be treated as external dependencies also.

It seems to me as much more complex (and probably not as useful) to use project dependencies as keys to resolving external library dependencies. As you say, the project dependences are in the workspace (I know). I also know for sure that specifying a project dependency is something completely different from linking to a library. It is therefore much cleaner to let project dependencies remain what they are: A specification of a build sequence.

So because of all this, my suggested solution was and is the way I wrote it: Just treat the existing list of input libraries within a single project as likely candidates for being external dependency files for that very same project. Then give the user an option to say whether those libraries are actually to be treated as such: a check-box option. The default value is not important (I would suggest activated, but keeping it deactivated would introduce no incompatibilities with existing projects). Such a feature does not replace the external dependency feature that exists today, it just makes it much easier for common situations.

Well, at least I am glad you understood my pain  :wink:

----
An unrelated sidenote: Another very minor thing in workspace files is that  active="1" option
Code
 <Project filename="project.cbp" active="1">
It does not really belong there (should be in some other file). When you keep files in a source control system you always end up with a modified workspace file, even though you only switched the active project and nothing else. But it is very minor, don't let it distract from the above.


Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #7 on: June 19, 2011, 11:11:23 pm »
An unrelated sidenote: Another very minor thing in workspace files is that  active="1" option
Code
 <Project filename="project.cbp" active="1">
It does not really belong there (should be in some other file). When you keep files in a source control system you always end up with a modified workspace file, even though you only switched the active project and nothing else. But it is very minor, don't let it distract from the above.
I have a pending patch that resolves this by introducing a workspace layout file. However, it's not yet discussed whether we (the team) want that.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #8 on: June 20, 2011, 12:15:47 am »
Problem2: This is not a problem with source file times. I have checked, and every single source file is old. Only the files generated by Code::Blocks (such as *.depend) are new. No files are in the future. There is something else going on and it is rather annoying. It has been going on for some time, and that is why i post about it here. I usually try to solve my issues before asking. I will also check on another machine, to see if there is any different behaviour. Btw. I forgot to say I am using the nightly build 7215 from jens lody on Linux.

I have checked on another linux box. It shows similar behaviour, almost all code is always completely recompiled when no code changes have been introduced and only Build (not rebuild) is specified. The first project (that does not depend on anything else) somehow seemed to be detected as up-to-date (same on both computers), but the others gets full recompile every time. So I do suspect this has something to do with multiple levels of build dependencies between projects (static libraries here).

This stuff should be easier...

To Morten about the patch: Saw your message, thanks. Good to know you are aware of it.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #9 on: June 20, 2011, 12:30:20 am »
cacb:
If the times are OK, it will be best if you can provide a simple test workspace, so the bug could be found and fixed.
Else you'll have to debug C::B yourself to see what is happening.

I'm using external deps and I see no problems (except the tough setup).

p.s. you don't have to be a dev in order to provide good patches, in fact it is the other way round, you provide good patches and after a time you become a dev  8)
(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 cacb

  • Lives here!
  • ****
  • Posts: 536
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #10 on: June 20, 2011, 09:02:59 am »
cacb:
If the times are OK, it will be best if you can provide a simple test workspace, so the bug could be found and fixed.
Else you'll have to debug C::B yourself to see what is happening.

I'm using external deps and I see no problems (except the tough setup).

p.s. you don't have to be a dev in order to provide good patches, in fact it is the other way round, you provide good patches and after a time you become a dev  8)

Ok, that sounds good. I shall prepare such a test workspace, showing the same behaviour. It should be relevant for both Problem1 and Problem2. It will probably take a couple of days as I am very busy with my project now. The info from this thread has helped, though.

About being a dev: Yes, I know. I wasn't too worried about the formalities, but more the effort of figuring out how C::B works internally.

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: Problem using Project Dependencies, do they work in Code::Blocks?
« Reply #11 on: August 20, 2011, 06:33:26 pm »
Just a quick post on this issue to say 2 things.

1. I did not follow up on this issue in June, due to sudden illness in the family.
2. Recently, I discovered the cause of the problem and found the solution, described below.

The thing is that I had written a small utility that is executed as a post build step for every project. This utility copies header files, lib files and executables to a central area. When a project A depends on another project B, the A project is compiled against the B header files in the central area. The symptom I was seeing was that, on Linux, all C++ files were recompiled always, and the cause was that copying of header files to the central area gave them new date & times (the time of copying).

After modifying the copy utility, the copied files now always gets the exact same date & time as the originals. This solves the Linux massive recompilation problem completely as far as I can tell. The dependencies now seem to work as expected.

Si we can conclude there is no Code::Blocks problem