User forums > Using Code::Blocks
Problem using Project Dependencies, do they work in Code::Blocks?
cacb:
--- Quote from: oBFusCATed 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.
--- End quote ---
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.
cacb:
--- Quote from: killerbot 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 ....
--- End quote ---
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">
--- End code ---
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.
MortenMacFly:
--- Quote from: cacb on June 19, 2011, 11:09:03 pm ---An unrelated sidenote: Another very minor thing in workspace files is that active="1" option
--- Code: --- <Project filename="project.cbp" active="1">
--- End code ---
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.
--- End quote ---
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.
cacb:
--- Quote from: cacb on June 19, 2011, 10:31:46 pm ---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.
--- End quote ---
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.
oBFusCATed:
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)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version