Code::Blocks Forums
User forums => General (but related to Code::Blocks) => Topic started by: AngleWyrm on June 10, 2007, 09:48:51 am
-
(http://home.comcast.net/~anglewyrm/libtree.png)
-
Hi !
I find it is a nice feature that could be even nicer if supporting drag'n drop from explorer.
Dje
-
as nice as this would be, how would something like
in the "other linker options" be shown?
on linux its the most correct way to include some libraries. parsing this and showing it in the tree would be a possibility, but for some libraries it would be nonsense (since this command will pull quite a lot of *.a files).
Markus
-
i think just showing something like the complete sdl or wx-config command would be ok so user could also add manually commands and options to them in a nice way ;)
-
i forgot to write something about an even bigger problem!
say you have a few targets, each with its own linked libraries. which libraries should be shown?
if yo don't want a tree structure with every target this isn't going to work..
Markus
-
hey nice idear so you can manage the windows build in linux and copy it for a linux windows build made under linux for windows with gcc ;) i guess if it should be inserted then with every tree :) i also would like to have systemindependent project files for wxwidgets right from the assisten ;)
-
I find it is a nice feature that could be even nicer if supporting drag'n drop from explorer.
Hello.
And what would be the purpose for such feature? I suppose that the proper place for that drag'n'drop feature would be inside the project build options (the linker setup tab for each target), but i can't imagine his utility inside the workspace tree.
i forgot to write something about an even bigger problem!
Don't forget those libraries created "on the fly" (during compilation time) and used in the same workspace :)
so you can manage the windows build in linux and copy it for a linux windows build made under linux for windows
I have not understood that, but can already create your C::B projects with different Linux and Windows build targets in the same .cbp file, and work with them (editing both properties and build setups when needed) independently of the OS you were running at that moment.
Regards.
-
I find it is a nice feature that could be even nicer if supporting drag'n drop from explorer.
Hello.
And what would be the purpose for such feature? I suppose that the proper place for that drag'n'drop feature would be inside the project build options (the linker setup tab for each target), but i can't imagine his utility inside the workspace tree
I always work with an explorer and I would find very useful to be able to drag'n drop files (sources, other, libs) from explorer to the project tree. I don't like contextual menu and it would be faster than the classic "Build options/linker tab/add/browse for file..."
What would be the interest of this feature if linked libraries can not be modified through the tree ?
For sure, I'd like this feature being implemented for both tree and build options.
Dje
-
yeah i agree the critics are true but the drag and drop would be nice ;) so why notimplent that one in the build property pages ? i think this would be a good compromise !
-
I find it is a nice feature that could be even nicer if supporting drag'n drop from explorer.
Yes, that's exactly it: Visible and interactive.
say you have a few targets, each with its own linked libraries. which libraries should be shown?
The same way that is currently being used to display the source and header files for varying targets.
-
actually because of this thread i tried assigning files to different targets for the first time.
when i change the active target nothing in the project-tree changes :-/
(i am not sure if the tree is supposed to change, actually i didn't expect this)
to which target would dropped libraries be attached when the policy for the active target is "use project options only"? since you can't see this in the project-tree you run in the risk of invalidating all your others targets.
sorry if i sound too pessimistic. i acknowledge the usefulness of something like this. i just can't see how this should work :)
Markus
-
When right-clicking on a project and select "Add Files...", the only question asked is "To which targets does this file belong?" No further details are asked when adding files to a project. Do libraries require additional information?
For drag-n-drop, the most useful would be to have a normal (left-mouse) drag automatically apply the dragged files to all targets. For the more specialized files (debug, platform-specific, etc) one could have a right-drag that would call up the file properties dialog on completion of the drag-n-drop operation. Right-clicking a file is already in the current build, and brings up the properties, where the the build targets can be (de)selected.
-
Also take in mind that C::B supports several compilers, and each one has a different technology when dealing with libs; so how to adapt this architecture on a multiplatform-multicompiler-fullyportable-IDE ? (the linker settings are part of every compiler plugin, and that structure shouldn't be modified).
In my opinion it's great as it is right now :D
-
The way things are:
1).Go to Settings->Compiler->Link and add general libraries
2).Go to Project->Build Options->Project and add libraries for the project
3).Select individual builds (debug, release, etc) and add libraries for each build
Then let's say several months go by and Microsoft releases a new version of DirectX SDK. Spend some quality time mousing around trying to remember where each linked library goes. Hint: At least three of those lists of included libraries will need to be updated.
I am willing to understand how things got to where they are now, but I wouldn't describe them as "great".
-
AngleWyrm - if you use custom/global variables you can minimize some of this hassle to the point that updating settings is pleasant. For bigger jobs you can always just regex/script the xml project files. I also think Mandrav has plans to offer project settings hooks to squirrel scripts (if he hasn't done so already)
That being said, I see no reason not to have multiple ways of doing things. Task #1: add option to show only files of a specific target in the project tree (seems like a generally useful feature). Task #2: show libraries in the tree. Quite a bit of work there and not something I imagine any of the core team will want to work on before the next release.