Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Dependencies handling ?
Urxae:
Inter-target dependencies are implemented in the same way as inter-project dependencies: add the produced file to the external dependency list.
mandrav:
--- Quote from: zieQ ---I think using the order of the projects to get things compiled in the proper order is not the best idea.
--- End quote ---
May be so, but in the end that's what it comes down to: a list of projects to build, one after another. It just so happens that this list is visible all the time: It's the workspace view :)
--- Quote from: zieQ ---Worse, there's no easy way to move projects up and down in the workspace project list! For sure, using project dependencies would be better for that.
--- End quote ---
Try Ctrl-Shift-UpArrow and Ctrl-Shift-DownArrow ;)
Or programmatically:
--- Code: ---Manager::Get()->GetProjectManager()->MoveProjectUp(cbProject*);
// or
Manager::Get()->GetProjectManager()->MoveProjectDown(cbProject*);
--- End code ---
These are not easy ways?
--- Quote from: mandrav ---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).
--- End quote ---
And, as you can see, I finally understood what you 're saying :)
--- Quote from: mandrav ---You have to excuse me because I have never used any Microsoft IDE, so their terminology eludes me...
--- End quote ---
I thought I 'd quote this to emphasize it. In simple words: if you can't contribute code that does what you 're saying, the least you could do is provide detailed info on this thing and possible implementation details.
Yiannis.
zieQ:
--- Quote from: mandrav ---Try Ctrl-Shift-UpArrow and Ctrl-Shift-DownArrow
[...]
These are not easy ways?
--- End quote ---
Sorry I tried dragging the project and looking at the contextual menu and I didn't see anything about that! Ok :roll:
Not all my points are related to the build order: whatever the order I choose, the projects are not compiled as I expect it to be!
--- Quote from: mandrav ---I thought I 'd quote this to emphasize it. In simple words: if you can't contribute code that does what you 're saying, the least you could do is provide detailed info on this thing and possible implementation details.
--- End quote ---
I keep trying... :roll: I will explain how it is perform in Visual Studio: say we have a project A (exe) which depend on B (lib), then we have to:
- ensure B is up-to-date before any compilation/link for A
- if not, recompile B
- A will have the include paths of B added in its include paths (do not appear in the include options of the project), so as to compile properly with B.
- A is linked to B (do not appear in the link options of the project)
The extension to multiple dependencies:
- before compiling the currently selected project/target, compile all dependent projects (if necessary, but visual studio compile all and issue "up-to-date" strings)
- then compile/link the current project
RShadow:
--- Quote from: zieQ ---
I keep trying... :roll: I will explain how it is perform in Visual Studio: say we have a project A (exe) which depend on B (lib), then we have to:
- ensure B is up-to-date before any compilation/link for A
- if not, recompile B
- A will have the include paths of B added in its include paths (do not appear in the include options of the project), so as to compile properly with B.
- A is linked to B (do not appear in the link options of the project)
The extension to multiple dependencies:
- before compiling the currently selected project/target, compile all dependent projects (if necessary, but visual studio compile all and issue "up-to-date" strings)
- then compile/link the current project
--- End quote ---
forgive me if I put my foot in my mouth on this one.. I'm jumping into the conversation kind of late, but let me see if I get this right:
Lets see.. we have one workspace with two projects.
first let me get rid of the project a b c x y z stuff because it hurts my head :)
Project MyLib (library .. doesn't realy matter if its shared or static)
Project MyApp (executable that links to MyLib)
What you are wanting is when you manualy compile MyApp for it to automaticly detect any changes to MyLib and recompile MyLib if changes are present? If that is the case I believe that is what mandrav explained like 3 posts up. I'm not sure if C::B automaticly detects this, but it seems a little backwards to me. If I make changes in MyLib then I would compile MyLib ..which would make MyApp's depends list dirty and force MyApp to recompile as well. You want MyApp to autocheck MyLib for changes, but if MyLib changes then I already know about it.. well because I changed it.. I guess it just makes sense to me to build bottom up.. If I make a change to a library then I'm going to recompile that library before I recompile the app that links to it. anyways having C::B setup a dependency list / build order wouldn't be too difficult, however I think most of the dev's are working on other stuff right now(like unicode support, and documentation to name a few).. perhaps you could submit a patch set with limitied funcationality of what you would like and then somebody could take it from there.
You also want MyApp's include path to have the same include path as MyLib (I think this is already possible, just add the common paths to the global compiler include paths)..
One thing I would keep in mind is that MSVC has been in development since the 80's and C::B is still a beta software..so you can't expect C::B to mimick the exact functionality of MSVC. Personaly I think an IDE should only provide basic linking capabilities internaly. If a more complex build solution is needed there are a lot of tools for that. (Perhaps writing plugins to interface with those tools is a good idea.. some of which are already being worked on). There are lots of tools to solve complex build senerios that have been around for a long time, and they still don't get it completly right.
zieQ:
--- Quote from: RShadow ---I'm not sure if C::B automaticly detects this, but it seems a little backwards to me.
--- End quote ---
The answer is not! I do not figure out why it is backwards to you ?!
--- Quote from: RShadow ---If I make changes in MyLib then I would compile MyLib ..which would make MyApp's depends list dirty and force MyApp to recompile as well. You want MyApp to autocheck MyLib for changes, but if MyLib changes then I already know about it.. well because I changed it.. I guess it just makes sense to me to build bottom up..
--- End quote ---
Yes, that's really simple in your case: one library, one executable. To illustrate my problem, I'm currently working on a big project. There's about 30 projects in my workspace, with complex dependencies (more than 1 level, an executable which depend on a library with depend on...), with many files opened at the same time from several projects. In my case, it is not easy, evident, straightforward to remember all the dependencies, or worse which projects the files belongs to.
That's why I need the dependency feature, I'm could not live without. Projects dependencies allow faster coding since we do not have to remember all the dependencies, and to compile every time I modify a file. That's my habits :roll: , and it seems really useful to every people I know using the Visual environment.
--- Quote from: RShadow ---One thing I would keep in mind is that MSVC has been in development since the 80's and C::B is still a beta software..so you can't expect C::B to mimick the exact functionality of MSVC.
--- End quote ---
That's not what I want. I just want to discuss it, to ear the opinion of the main developer and issue a feature request! As I said, I could not live without, so if the main developers agree with this new functionality, ok, I will help implementing it in the core SDK or give some feedback, otherwise I'll switch off using CodeBlocks. So I want some feedback from them. Moreover, this could not be implemented as a plugin since it imply modifying core sdk files (cbproject files) !
PS: could I commit modifications on the CVS, how ? Should I be registered as a regular developer ? (for visual workspaces imports)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version