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

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5258
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: 4305
    • 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: 5258
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: 4305
    • 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: 5258
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: 5258
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: 5258
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: 5258
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: 5258
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: 9606
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: 5258
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: 9606
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: 4305
    • 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...