Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

several issues with "open #include file ..."

<< < (2/7) > >>

killerbot:
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 ..) ;-)

Urxae:
What about this:

--- Code: ---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>"
--- End code ---

The interesting part being:

--- Code: ---#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.
--- End code ---
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).

killerbot:
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

killerbot:
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)) ?

Urxae:
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 ;).

Navigation

[0] Message Index

[#] Next page

[*] Previous page