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