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

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
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: 4315
    • 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: 5490
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: 4315
    • 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: 5490
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: 9694
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: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
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: 9694
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: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • 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: 5490
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: 5490
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: 4315
    • 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: 5490
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: 9694
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: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
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