Author Topic: several issues with "open #include file ..."  (Read 18485 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
several issues with "open #include file ..."
« on: November 25, 2005, 01:35:36 pm »
I will also create a bug report with attached project on the SF page.

Open include file does NOT work for C++ header files.

When looking at the code of the "Open include part" of the codecompletion plug-in, there are several directories added to a list, where a search will happen to find the "#include file". This is done by calling Parser::AddIncludeDir() fromp within NativeParser::AddCompilerDirs()
These are :
 - the project's base path
 - include dirs specified in the project
 - include dirs of the target
 - include dirs from the compiler

In the attached example (with default installation of CB 'with Mingw'; note : also happens with cvs build), these are
 - <MyProjectPath>   (the project base)
 - <MyProjectPath>\inc (include dir specified in the project)
 - C:\Program files\CodeBlocks\include  (the compiler include dir)

Well ,the last one is incorrect, at that level you can for example find "stdio.h", but not the real C++ header, they are in :
C:\Program files\Codeblocks\include\c++\3.4.4  !!!
When I add this include dir to the gnu compiler settings I can "open include file iostream", otherwise I don't.

I think there are 2 solutions :
1) the include paths for the gnu compiler in the colmpiler setting should have this entry also

2) apparently the compiler is able to find those header files during compilation, does it have this extra path build in ? or can it figure it out otherwise (environment?) -> if CB also could figure this out, it could registrate also this/these extra path(s) ??


The second problem is :
In the attached project switch to the digital mars compiler (includes path for that compiler are for example : C:\dm and c:\dm\stlport\stlport).
Save the project, close it, open it
The include paths of the digital mars are not added to the parser::AddIncludeDir(), once again it are the include paths of the gun compiler which are added.


What do you think ? And ... when could it be fixed ? ;-)

The fix for problem 1 through solution 1 could be simple, I guess. Since during the autodetect CB finds out where the gnu compiler is.

kind regards,
Lieven


[attachment deleted by admin]

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: several issues with "open #include file ..."
« Reply #1 on: November 25, 2005, 02:11:53 pm »
Quote
1) the include paths for the gnu compiler in the colmpiler setting should have this entry also

Then we would face many problems when we make a release with newer MinGW...
The compiler knows how to locate its files, no need for us to help ;)

Quote
2) apparently the compiler is able to find those header files during compilation, does it have this extra path build in ? or can it figure it out otherwise (environment?) -> if CB also could figure this out, it could registrate also this/these extra path(s) ??

It's built-in to the compiler...

Quote
The second problem is :
In the attached project switch to the digital mars compiler (includes path for that compiler are for example : C:\dm and c:\dm\stlport\stlport).
Save the project, close it, open it
The include paths of the digital mars are not added to the parser::AddIncludeDir(), once again it are the include paths of the gun compiler which are added.

If it is indeed so, then it's a bug. It 'll be fixed after we move the repository.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #2 on: November 25, 2005, 02:54:01 pm »
so for the first problem that means if we don't add it, we can't open c++ headers, like iostream, vector, ... :(

That would be a serious lack in functionality.

Question, what would CB do, when I have 2 gnu compilers installed, lets say 3.4.4 and 4.0.0 ?
Assume, an installation of CB is done, with the distribution that does not contain the gnu compiler.


Cheers,
Lieven

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: several issues with "open #include file ..."
« Reply #3 on: November 25, 2005, 03:26:28 pm »
Quote
so for the first problem that means if we don't add it, we can't open c++ headers, like iostream, vector, ...

You can always add it yourself ;)

Quote
Question, what would CB do, when I have 2 gnu compilers installed, lets say 3.4.4 and 4.0.0 ?

It will use the one that is configured, probably by its auto-detection.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #4 on: November 25, 2005, 05:49:46 pm »
hmm, ironical critical grumbling noise for the solution  :P

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #5 on: November 25, 2005, 05:53:46 pm »
stupid idea for ilplemented workaround, is that version numbering standard for MingW ?
Otherwise we could ask G++ for its version number (with the beautifull command "g++ --version"), parse the result and construct and in the code that registers the include dirs for the "open include file" stuff, we could add this extra include directory.

Damn damn, things are getting dirty, but it would solve the problem ..

What do you guys think (don't be to sarcastic in shooting the idea down ..) ;-)

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: several issues with "open #include file ..."
« Reply #6 on: November 25, 2005, 06:53:25 pm »
What about this:
Code: [Select]
D:\> g++ -v -E -x c++ - < nul
Reading specs from D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --
disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --
disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libst
dcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
 D:/C++/MinGW/bin/../libexec/gcc/mingw32/3.4.2/cc1plus.exe -E -quiet -v -iprefix D:\C++\MinGW\bin/../lib/gcc/mingw32/3.4.2/ -
ignoring nonexistent directory "D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/include"
ignoring nonexistent directory "/mingw/include/c++/3.4.2"
ignoring nonexistent directory "/mingw/include/c++/3.4.2/mingw32"
ignoring nonexistent directory "/mingw/include/c++/3.4.2/backward"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.2/include"
ignoring nonexistent directory "/mingw/mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/mingw32
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/backward
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/include
End of search list.
# 1 "<stdin>"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "<stdin>"

The interesting part being:
Code: [Select]
#include "..." search starts here:
#include <...> search starts here:
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/mingw32
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/backward
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/../../../../include
 D:/C++/MinGW/bin/../lib/gcc/mingw32/3.4.2/include
End of search list.
Looks very parsable :D
Normalization of the paths may be in order, but that should be simple (I think wx even provides a simple way to do it).

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #7 on: November 25, 2005, 11:51:55 pm »
Urxae,
This looks very helpfull, even better, since there are even more include paths then the one I was focusing on.
I'll try to implement it this weekend, have it up for review and then the almight Mandrav can decide upon that newly generated code's faith.


aaah, those ../../../../../../../../.. , don't you just love them, upstairs, downstairs ...

Cheers,
Lieven

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #8 on: November 26, 2005, 12:35:49 pm »
first experiment is not that successfull (yet?).
The call does not return, I do something like this :
   wxString Command("-g++ -v -E -x c++ - < nul");
//   wxString Command("mingw32-g++ -v -E -x c++"); // everything shows up on the error stream
   wxArrayString Output, Errors;
   wxExecute(Command, Output, Errors);

It seems like the part < nul is not being taken into account, since that causes the call to return, when typing it in manually in a dos box.

Any ideas (preferably not to dirty (so no wait a bit and send a kill to the process)) ?

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: several issues with "open #include file ..."
« Reply #9 on: November 26, 2005, 01:10:09 pm »
Well, "< nul" is basically a nice way of saying "input ends immediately". When running the command from wxWidgets you should leave that off, redirect and close input immediately. You'll have to run it asynchronously to do this, though, which adds other complications. In particular, it seems to be a bit of work to determine when the process has ended and you can read the output.

You can also just specify an empty temporary file instead of the "-" at the end, which makes it a lot simpler. If it has a C++ (not C) extension gcc recognizes you can even leave off the "-x c++" I think, as that was just a hack to get it to recognize stdin as a C++ file.
Using this method, your version of the wxExecute call should work, provided you make the above changes to the command line and create an empty temporary file to match. Don't forget to delete it again when you're done.
Of course, you can skip those steps by distributing empty.cpp in a data directory ;).

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #10 on: November 26, 2005, 05:01:04 pm »
 :lol:  :P
Problem 1 is solved, in a next post I will describe my analysis of the second problem (but have to go now).

Attached is the modified file : nativeparser(new.cpp), thanks to Urxae for the tip.

What did I do :
I check to see which compiler it is, when it is the GNU GCC compiler, i'll do my little magic. I find out the compiler's internal include diectories, and add them to the toher include dir's list.
I create a temporary file for this purpose which I delete afterwards.

The modified code can be found between the lines :
      // start of new stuff by Lieven de Cock
      // end of new stuff by Lieven de Cock
together with an include at the top for the regex functions.

There's one TODO left, I just create the temp file, without checking where we are (and if we can actually create a file at that place), maybe we should check the environment for the temp dir (does that exist in linux ??). On windows I saw that the temp file showed up next to the Cb executable and then nicely disappears. ;-)

So to summarize, these adjustments to the code allow you for GCC projects to "open include file" the C++ headers.

Yiannis,
I hope this code is OK for you ?

Note : I think a better place for these steps might be in the autodetection of the gnu compiler, and then add them to the include dir's list which is also visible in the GUI. So in that case my earliest idea fo a solution will still work even for other version of the gnu compiler. Yiannis, I leave this up to you. ;-)

Cheers (as promised further analysis for the second problem coming up),
Lieven


[attachment deleted by admin]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9595
Re: several issues with "open #include file ..."
« Reply #11 on: November 26, 2005, 07:09:27 pm »
There's one TODO left, [...]
Just a hint: I never did very much with wxWidgets but I believe that there is a wxTempFile that does the job: http://www.wxwidgets.org/manuals/2.6.1/wx_wxtempfile.html.

Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #12 on: November 26, 2005, 07:20:00 pm »
Thanks for the wxTempFile info, I just looked at the explanation. I am afraid it won't help for the TODO, since there's no file to replace, si no guarantee that we are at a writable position.
Nevertheless, interesting function, I just learned some more stuff , thank you.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9595
Re: several issues with "open #include file ..."
« Reply #13 on: November 26, 2005, 08:05:36 pm »
Nevertheless, interesting function, I just learned some more stuff , thank you.
...you might want to learn even more:  :)
http://www.wxwindows.org/manuals/2.6.2/wx_wxfilename.html#wxfilenameassigntempfilename

Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: several issues with "open #include file ..."
« Reply #14 on: November 26, 2005, 08:11:00 pm »
Quote
There's one TODO left, I just create the temp file, without checking where we are (and if we can actually create a file at that place), maybe we should check the environment for the temp dir (does that exist in linux ??). On windows I saw that the temp file showed up next to the Cb executable and then nicely disappears.

You should use wxFileName::CreateTempFileName() ;)
As for the patch, I 'll have a look at it, thanks.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #15 on: November 26, 2005, 10:16:38 pm »
is it correct that the file should then be destroyed by a regular call to ::wxRemoveFile(filename returned from CreateTempFileName), or should antoher specialised funtion be used ??

Tomorrow I will adapt the code with this change and post it again.
And as promised explain the second problem in more detail.
And uninstall my tortoise cvs and start using (tortoise)svn ...

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: several issues with "open #include file ..."
« Reply #16 on: November 26, 2005, 10:22:02 pm »
is it correct that the file should then be destroyed by a regular call to ::wxRemoveFile(filename returned from CreateTempFileName), or should antoher specialised funtion be used ??

Yes. This function returns a *proposed* filename for a temp file. It doesn't acually create the file. It just returns a unique filename in the system's temporary directory.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #17 on: November 26, 2005, 10:30:47 pm »
Yiannis, it does create the file " ... If the function succeeds, the temporary file is actually created.  "
As shows also the attached updated path (works for me).


[attachment deleted by admin]

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: several issues with "open #include file ..."
« Reply #18 on: November 26, 2005, 10:45:26 pm »
Yiannis, it does create the file " ... If the function succeeds, the temporary file is actually created. "
As shows also the attached updated path (works for me).


Right, sorry for the confusion (should read the docs before touching the keyboard :) ).
Still, you can (and should!) delete it when done with it.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #19 on: November 27, 2005, 10:51:31 am »
allrighty, here we go with the analysis of problem 2 :

First some things to take into account :
1) a project (.cbp) can have several targets
2) a project can have specified include directories
3) a project can have a specified compiler (which has it's include dirs)
4) a target can have specified include directories
    -> additional
    -> Question 1 : what if it should overrule, so a header file, which is in the target include dirs and the project/project compiler include dirs, should be retrieved from the target ones --> order does matter
5) a target can have a specified compiler
   -> OVERRULES the project compiler
   -> project compiler include directories should be OUT of the picture
6) several targets in the same project can have different include dirs, it is well possible that a given header file might exist in those 2 different include dirs sets

Now when we focus on the NativeParser::AddCompilerDirs() method
1) we add the project base as an include dir to the include dir list (for example for the gnu compiler this path is NOT taken into account during compilation) --> maybe it should be ommitted in this context (open include file) also ?
2) the "project compiler" is retrieved !!
3) the project include dirs are added to the list
4) for EVERY target, the target include dirs are added to the list
5) for the compiler retrieved in step 2, the include dir's are added

So as far as my second problem goes, the cause of the problem is step 5, we add the project compiler, though the target has a different compiler.
The following snippet from the cbp shows this :
   <Project>
      <Option title="Codec"/>
      <Option makefile="Makefile"/>
      <Option makefile_is_custom="0"/>
      <Option active_target="0"/>
      <Option compiler="0"/>
      <Build>
         <Target title="default">
            <Option output=".objs\libCodec.a"/>
            <Option working_dir=""/>
            <Option object_output=".objs"/>
            <Option deps_output=".deps"/>
            <Option type="2"/>
            <Option compiler="3"/>
            <Option projectResourceIncludeDirsRelation="2"/>
         </Target>
      </Build>
If we would set the project compiler also to '3' (== digital mars), everything works ok again, but then a second target using the gnu compiler is in trouble. Since we are opening the wrong (in this case C++) header file.

---->
Solution action point 1 : we should not use the project compiler, but the compiler of the target (it seems like that one is always specified)

Solution action point 2 : (follows from action point 1) , the AddCompilerDirs method needs to be invoked from the top level on, the moment the target is switched !!!

Question 2 : does it make sense to specify a project compiler ? Could be since it can be used by default for every newly added target, but for sure it should not be taken into account in out context here

Looking more closely at step 4. it is obvious that not all targets include dirs should be put together in 1 list.

---->
Solution action point 3 : Only the include dirs of the current selected target should be added to the list. As a result of this, again we need action point 2.


Question 3 : What should we do when the current selected target is 'all' ?? I feel that the 'all' is intended here more to the build process, build every target, and not to the code editing process. Maybe in case of all, we should stick at the 'default' target (or first target in the cbp file), or at the last selected target. Meaning switching to the all target should not trigger the AddCompilersDir actions (or we deal with it in the AddCompilerDirs method).

Note that it might be a bit annoying that if you always want to build every target at each step you change a little bit of code, you might not be using the include set you want, to use to correct include set, you should be working (build selection) directly with the desired target.

Some other times where the AddCompilerDirs actions should be triggered, is when you change for the current active target the compiler set. Obvious we need to recompile (CB even reminds us of that), but CB should change the include set in the background.
This can be easily shown that it is needed.
For example create a new project (leave everything as it is, so just the simple hello world main -> notice how it includes iostream -> using the patch for problem 1, we can open include it). Before you do anything else, go to the project build properties, and change the compiler (eg digital mars) (go ahead take the top level, so not just for the default target, cb will ask to use for every target, say yes). Now go back to main.cpp and open include iostream --> still the iostream of the gnu compiler. Why ? Since no retriggering of the AddCompilerDirs actions. When you close and reopen the project then in this case the things work fine, but just 1 step too late.

So what do you think ??
I will already start to adjust the AddCompilerDirs method to use the target compiler, use the selected target include dirs (when target is all, I'll switch to the first one). Yiannis, if ok, could you do the retriggering the moment the user changes the compiler of the active target, or when he switches targets within the project ? Or just pinpoint me to the correct spots then I can try it myself, but not sure if my knowledge level is already sufficient is those other areas.


kind regards,
Lieven

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9595
Re: several issues with "open #include file ..."
« Reply #20 on: November 27, 2005, 11:20:00 am »
allrighty, here we go with the analysis of problem 2 : [...]
I am sorry, but can I ask to go a step back? I have somehow lost the point of this discussion. :( I have understood why you want to add the mingw version special directories (for the includes), but what are you trying to solve with the latest post? What is "problem 2"? Could you please explain this to me in a short proposal? That would help me... sorry.

Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #21 on: November 27, 2005, 11:55:01 am »
Morton,

As mentioned in the start of this thread :
The second problem is :
In the attached project switch to the digital mars compiler (includes path for that compiler are for example : C:\dm and c:\dm\stlport\stlport).
Save the project, close it, open it
The include paths of the digital mars are not added to the parser::AddIncludeDir(), once again it are the include paths of the gnu compiler which are added.

More details in my previous post on what goes wrong.
Shortly stated : project top level says gnu, target says digital mars -> so when I open include a c++ header , I should get the one from digital mars and not the gnu one.

Hope this makes it clear,
Lieven

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9595
Re: several issues with "open #include file ..."
« Reply #22 on: November 27, 2005, 12:10:47 pm »
Hope this makes it clear,
It did, thanks. But: I cannot reproduce the issue you have explained. I've opened your project, compiled it with the default compiler (mingw). Then I changed the compiler for this project to Digital Mars. C::B complained I should recompile, so I did. I re-build the project which was now done with DM and worked. Then I closed C::B (and saved the changes  done to the project). I re-opened the project and re-build it again (without changin any settings). It was compiled with the DM compiler again and was still working also the include path's were set correctly to the ones of DM...

Am I still missing something?

Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: several issues with "open #include file ..."
« Reply #23 on: November 27, 2005, 12:17:32 pm »
Hi Lieven

I think you 're over-complicating things. Not that what you said isn't true, but you have tied your thinking to the selected target which has nothing to do with the functionality of "open #include".
The way it is structured now, allows it to work even for single files, not belonging to a project.
Even if you 're only working with project files, you should be able to locate #includes in files not belonging to the project or the currently selected target.
With your suggestion, before using "open #include" in a file, I should manually select the file's target to work (and this wouldn't work always).

I have an easier solution for you.
Leave it as it is now, but instead of breaking out of the search when the first match is found, continue searching. If at the end of the search more than one files were located, display a nice selection dialog for the user to choose :)
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #24 on: November 27, 2005, 12:21:02 pm »
Morton,

Yes you are missing a little thingy  :)

in one of the files do "open include file" on one of the c++ headers (or just type an #include <iostream> in one of the files and do it on that one). You won't be able to open it (that was problem 1 which I fixed, just grab the code attached somewhere above), and then with your recompiled version, try again, you'll end up in the wrong iostream header, the one from gnu not digital mars.
So COMPILING is OK, but the "open include file" funtionality is not.

Cheers,
Lieven

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #25 on: November 27, 2005, 12:27:25 pm »
Yiannis,

Might be a good idea, for the multiple hits to provide as a list.
I'd have another look for the 'single file' case. For example in this case it should be the default compiler set, etc ..
I know it might be over-complicated  :P.
I just tried to think of nearly every situation without bothering the user, well in each solution we bother the user, either have the user set the correct target or have him select from multiple hits.

Does your remark also apply to the compiler ? Because there it is for sure a bug, don't think we should allow for selection here. Your target (or your single file) is using 1 and only 1 compiler. Allthough we again end up at the same problem when the target is 'all'.

What if the target is a dedicated one, we make sure we are using the correct compiler include dirs set, and in the case of 'all' we allow the selection out of multiple hits ?

Lieven


Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4291
    • Code::Blocks IDE
Re: several issues with "open #include file ..."
« Reply #26 on: November 27, 2005, 12:34:06 pm »
Quote
Does your remark also apply to the compiler ? Because there it is for sure a bug, don't think we should allow for selection here. Your target (or your single file) is using 1 and only 1 compiler. Allthough we again end up at the same problem when the target is 'all'.

And I ask you again: what if the target is "all" (which is frequent), or we 're talking about a file without a project?
I often double-click a file in explorer, it opens in C::B and I start following #includes. The way it is now, it is working. And it's a simple piece of code to debug, if it wasn't working as expected.
If we did the modifications you 're suggesting, we 'd have some complicated code (harder to debug) and it wouldn't work in many cases.

So, I still think a selection list might be the best option here (only if we have more than one match). It's the only user-input we 'll ever need.
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #27 on: November 27, 2005, 12:53:14 pm »
I do agree with your arguments.
Just let me show some example where 'both' might be usefull.

The situatio at our company, is we use several compilers. We create code that should work on different 'embbedded' platforms. Therefor we use the WindRiver compiler, the TI compiler. We have a pc model of the code also, so we also use, gnu, digital mars, Microsoft ...
Also good coding practices advice using several compilers (they all come up with different errors/warnings).

Most of the time we work in one specific environment for development and compile early/often with a specific compiler. And then after some time, we build the code with all compilers (if cbp, you can think as every target of the same code using a different compiler). That means each time we want to open include a c++ header (I agree here, this does probably not happen that often, one more argument for Yiannis I have to say), we get the list (probably every compiler set will have a hit), so we select from the pop up list.
This WORKS, so Yiannis you are right !

Might get irritating after a while (depending on the rate of open including c++ headers).
Might be nice that there might be another way of doing things (user selectable).

Again I agree, more code, more chance for bugs, less easier to debug.
Thoug I noticed that in RC2 rebuild all, always had a nag screen, and in the current cvs, excuse me, svn code, you can tell CB to stop the nagging and just rebuild all. --> More code ...  :D
Off course the frequency of rebuilding all is way higher thet open include c++ headers.

So we agree on adjusting with a pop-up list or something like that (might need some help here, but I'll do my best) and we can always see after that.

Yiannis, how do we solve the problem when the compiler has been changed for the project or for a target that the retriggering happens for the AddCompilerDirs() ??

Lieven

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9595
Re: several issues with "open #include file ..."
« Reply #28 on: November 27, 2005, 01:05:33 pm »
Yes you are missing a little thingy  :)
Aaaah! Now I got the whole picture (sorry for taking so long... :? ). So it was still about the includes - I tried and can confirm. I never did such things. My full respect that you take your information about the C++ API's and stuff directly from the header files... :shock:
That I'm reading this topic was because in fact I was thinking more in a different direction: Locating the C++ header files for code completion and stuff... A big sorry for the confusion.

Morten.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #29 on: November 27, 2005, 04:16:42 pm »
Yiannis,

just discovered another issue.

Make sure you close every project in CB, through the windows explorer double click a cpp file (with next to it (== in the same dir) it's header file).
Now in the cpp file (make sure it includes it own header), try to open include that header --> FAILS.
You can however do a successfull swap header source !

If you open a project (which does not include the 2 files from above) then it does work.

Things go wrong in CodeCompletion::OnOpenIncludeFile() :
In the first case (no project open), we get NULL back from m_NativeParsers.FindParserFromActiveEditor(), so we try to get it from the m_NativeParsers.FindParsersFromActiveProject() call.
In the first case there's no project -> NULL -> function returns.
In the second case we get a valid pointer. Then we try to find it by searching all the parsers include paths, no result for this, and then we try in the same dir --> bingo, found it.


So the problem is when there's no project, how do we get a valid parser.

I think , the swap header source should be looking for it's header/source buddy also in the includ dirs (is this correct?). If so : how comes that one can find it.

Can you give me a pointer to the solution, then I can add to my other fixes.

greetings,
Lieven

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Re: several issues with "open #include file ..."
« Reply #30 on: November 27, 2005, 04:20:20 pm »
my simple solution suggestion is, don't return if no parser, search the parser includes only if there's a parser pointer.

And eventually (even in the case, there's no parser) we end up at the search in the same dir, which does not use a parser).

Lieven

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5242
Array
« Reply #31 on: November 30, 2005, 10:07:26 pm »
Yiannis,

Attached zip file contains the changed code files (checked against the latest svn version to see the changes).
This is what happened/changed

1) Changes to parser.h/cpp
 - no longer uses wxPathList, but again wxArrayString : to allow to return several hits, for the case the searched include files exists in several include directories --> a wxArrayString is returned with all this hits ; no hits => GetCount will return 0
 - const function
2) CodeCompletion.cpp
 - in case no parser, continue so we can still look in the same directory as the file were the open include was generated (see post above explaining the bug)
 - check the return set (found set) : if more then 1 hit -> show dialog box with the list that let's the user select the header file he actually wants, if 1 hit don't show dialog box, also don't show it if no hits and continue search (same directory)

3) new files :
 - SelectInclude.wxs/xrc -> wxSmith for creating the dialog
 - SelectInclude.h/cpp generated and implemented code for the dialog box, setting the hits, and selecting the 'use choicen' hit

4) nativeparser.cpp
 - add include path of all compilers (project compiler/ target compilers)
 - in case one of those is the gnu compiler, to the special trick to find out the other includes paths (internal ones of the gnu compiler -> so c++ header files can be found -> see also above post for more details)

That's it : this has solved the 3 bugs, it works on my installation.

5) action.jpg : snapshot of the dialog with the selections on the project attached in an above post (with gnu and digital mars compiler), when include open the cstdio from the source file codec.cpp.

kind regards,
Lieven


[attachment deleted by admin]