Code::Blocks Forums
User forums => Help => Topic started by: Mike on January 19, 2005, 08:42:37 am
-
Hi mandrav,
It would be quite useful to have a "Go to definition" option in the right-click menu for a function or variable. It should also work for standard functions like "strncpy".
Mike
-
Hi again,
Another nice feature would be to enhance Help to go to MSDN to look up the function description.
Mike
-
Yet another suggestion.
It would be much nicer to have project directories in the workspace file defined as relative to the workspace directory. This will simplify sharing the sources by different people.
But in any case, as I can see your primary goal is not feature blowning, but stability of the product. Please, keep that goal no matter what! This is why people choose C::B instead of DevCpp, this is extremely important for developers.
Thank you for your marvelous job.
-
Another good spot for improvement is to clean up the file list. I have a structure like this:
- proj
- c.workspace
- c.cbp
- src
- a.c
- b.c
Then in the project view I created a folder "Source files" (it was in fact created by importing an MSVC project). In this folder I now get subfolders like this:
- Source files
- ..
- src
- a.c
which is rather weird.
Was it made so intentionally? If so, I'd like you to consider putting only the last subdirectory, as a menu item ".." looks bizzare.
P.S. Yiannis, could you please let me know whether you have read these proposals?..
-
P.S. Yiannis, could you please let me know whether you have read these proposals?..
I read everything 8)
You may not get an answer immediately but I do take all suggestions under consideration.
Keep 'em coming :D
Yiannis.
-
Good :-)
Then take this one as well: dependencies. I have a workspace with two projects, one producing a library, another one using it. I couldn't find a way to tell to the second project, that it depends on the result of the first one, nor that it depends on a particular library. That leads to the following workflow for me:
- Modify something in the library project
- Right-click, Compile
- Right-click on the exe project, Rebuild
- Click on "Yes"
- Click on Run
It'd be nice if I just could click on "Compile & Run" and get the dependency checker compile the first project.
-
In your workspace, open the library-project first and then the exe-project. When you make changes to the library, instead of hitting "Compile", hit "Compile/Compile all projects" (shortcut: Alt-C-J). This results in compiling the library and then the project :)
This reminds me that I should implement "Move up/down" commands for project ordering in the projects tree...
Yiannis.
-
This reminds me that I should implement "Move up/down" commands for project ordering in the projects tree...
Done. :lol:
Yiannis.
-
The second project still says:
mingw32-make.exe: Nothing to be done for `all'.
By the way, how do I get the latest changes? I am smart enough to get the sources from CVS (I believe :wink: ), but how do I compile them?
-
Hi Yiannis,
FIrst of all, thanx for the release. I have just installed it and wanted to try out the multiple-compiler thing, the one I wanted the most. It seems to compile both libraries fine, though I currently have some problems with the executable. The main problem I experience here is that there is a compiler setting for the top level of the target configuration, and if I set anything up on that level, it passes the things on as that compiler's options, so MinGW gets "/DWIN32" instead of "-DWIN32", and the like. Fixed by duplicating all options in the compilers' targets.
-
ANd the long-waited "error double click" feature did not come :-(
-
It also keeps complaining that "I changed the compiler used for the project." - what is this about?
-
Yet another useful feature would be specifying custom libraries for linking. It works okay for MSVC compiler, where I can provide a directory in "Link dirs", and a library name(s) in "Link options". But it does not work the same in MinGW, where I have to specify the relative path to the library in the "Link options"; it seems to ignore the "Link dirs".
-
Yet another useful feature would be specifying custom libraries for linking. It works okay for MSVC compiler, where I can provide a directory in "Link dirs", and a library name(s) in "Link options". But it does not work the same in MinGW, where I have to specify the relative path to the library in the "Link options"; it seems to ignore the "Link dirs".
It does work the same. The compiler plugin is one and the same. Support for different compilers comes from another configuration class, which has nothing to do with what you describe.
How do you add linker options in MinGW?
The right-way is, for a fictious library libfoobar.a, to add , i.e. -l (minus L), drop "lib" prefix and extension.
If you add the library like this, the compiler will find it only if it is in a lib path.
The other way is to use the full (or relative) filename of the library...
Yet, I see your point of adding libraries in a listbox and letting the compiler plugin pass it to the compiler, so you don't have to use different options for each compiler...
Yiannis.
-
Nope, alas, "-l" did not work - it still complains that the library file is not found.