Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Dependencies handling ?

<< < (2/5) > >>

mandrav:

--- Quote from: zieQ ---UP ? How could I set-up inter-project dependencies ?
Do you plan to add the related functions in the sdk soon ?
--- End quote ---

Projects are sets of build targets. This means a project may have more than one target generating output (an executable, a library, etc). There is no way to "link" two projects together in the form of one being depended on the other.
You can, however, make a target's output dependent on another target's output (even if it belongs to a different project). That's why you select as external dependencies only executables or libraries (shared or static).

If you don't understand what I 'm saying, say so and I 'll give you an example.

Yiannis.

zieQ:

--- Quote from: mandrav ---There is no way to "link" two projects together in the form of one being depended on the other.
--- End quote ---

We agree on that !


--- Quote from: mandrav ---You can, however, make a target's output dependent on another target's output (even if it belongs to a different project). That's why you select as external dependencies only executables or libraries (shared or static).
--- End quote ---

I really understand but this is not equivalent! I expect both targets to be recompiled if I modify something in the dependent target. Actually, if A is the currently selected target, A depend on B (a library) and I modify a .cpp file of B, none are recompiled except if I manually recompile B. The right way to do it is to depend on all executables/libraries/source files/user dependencies from the dependent target and that's a pain to set.

So, maybe you could add the "project dependencies" or "target dependency" feature. The main thing to do is to check that all the dependent project are up-to-date before proceeding to the compilation of the current project, and if not, perform the compilation of the dependent out-to-date project and relink.
In the SDK, 2 additionnal methods need to be implemented in cbproject.h /.cpp:

--- Code: ---addProjectDependency(wxString projectName);
wxArrayString getProjectDependencies();
--- End code ---


What do you think about that ? Could this be implemented in the SDK even if methods are empty, so that i will be able to solve a part of the visual import bug ?!

I advocate I really need this feature. IMHO workspaces are useless if there's no way to make dependencies between projects/targets. What's the point of having many projects displayed simultaneously if they are no dependencies between them, or if they do not recompile properly when we edit some files?! Code::Blocks is great but without this feature it's unusable to me. I'll switch off using it if if this is not implemented but that would be a shame !

I keep trying to solve the visual workspace import bug but this is the main problem to the conversion for now.

kagerato:
If you need the functionality that badly and believe it is simple to implement (judging from your post, it seems to safe to establish both premises), it seems quite reasonable to code it yourself.

I don't agree that workspaces were developed for the sole purpose of managing interdependent projects, and you truly have not offered any evidence for that assertion.

mandrav:

--- Quote ---I really understand but this is not equivalent! I expect both targets to be recompiled if I modify something in the dependent target. Actually, if A is the currently selected target, A depend on B (a library) and I modify a .cpp file of B, none are recompiled except if I manually recompile B. The right way to do it is to depend on all executables/libraries/source files/user dependencies from the dependent target and that's a pain to set.
--- End quote ---

I don't believe you understand what I 'm saying.

Example:

Project A is a static library.
Project B is an executable that is linked with the static library of project A.
We want B to depend on A, so if anything is changed on A, B is updated.
Do we agree so far?

C::B allows you to set A's product, the static library, as a dependency for B's product, the executable. This is done by going to project B's properties and adding A's library as an external dependency to the B's executable target.
Clear so far?

When you change something in A, say a .cpp file, this makes A dirty so it will be compiled and linked.
When A's static library is linked again, B's executable has dirty external dependency (the relinked A's static library).
Here is the point now: if nothing's changed in B and you try to compile it, it will get re-linked because it depends on a static library which is set as an external dependency.

This is the best I can explain it to you. If you still can't understand it, maybe someone who does and is more fluent with English than me can step in and explain it better.

On another note, it just occured to me you might be talking about projects build order inside a workspace. If that's the case, then the only useful hint I can give you is that projects are built top-to-bottom, as seen in the workspace tree. This means if a project A must be compiled before project B, A must be above B in the project tree. Then a "Compile->Compile all projects" will do the trick (i.e. build all in the right order).

You have to excuse me because I have never used any Microsoft IDE, so their terminology eludes me...

HTH,
Yiannis.

Profic:
I seemed understand what zieQ wants (using A and B from your post):
he wants automatically (not manually) compile and link A if something changed in it when he tells to compile and link B. And after this compile and link B.
Is it clear? Or I misunderstand something, too...

Navigation

[0] Message Index

[#] Next page

[*] Previous page