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