RE: [cdt-dev] Order of User-defined and Built-in includes/macros (was:Ho

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

Hi Mikhail,

I just checked the Intel C/C++ documentation for include path ordering
and it says:

The Intel(r) C++ Compiler searches the default system areas for include
files and whatever is specified by the /I compiler option. The compiler
searches directories for include files in the following order:

  Default include directory 
  Directories specified by the /I option 
  Directories specified in the environment variables

It looks as if it searches the "built-in" paths first.  I'll double
check with the compiler developers to make sure that the documentation
is correct.  I suggest that we not change this now, and look for a way
to make it customizable (per tool) in the future.

Thanks,
Leo 

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Sennikovsky, Mikhail
Sent: Wednesday, May 24, 2006 10:07 AM
To: CDT General developers list.
Subject: [cdt-dev] Order of User-defined and Built-in includes/macros
(was:How to get CDT parser to search -I includes before default
includes)

Hi all,

It seems reasonable for me to prepend user-defined includes and macros
instead of appending them as done currently in MBS, since I assume this
is really the most common behavior for most tools including gcc.

The reasonable order seems to be:

1. User values defined via options
2. User values defined via environment
3. Tool built-ins

Does anyone have any concerns or disagreements about the above order?

Regards,
Mikhail

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Jason Brown
Sent: Wednesday, May 24, 2006 5:00 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] How to get CDT parser to search -I
includesbeforedefault includes

Mikhail,

> Hi Jason,
>
> User-defined includes and macros are always appended to the built-in
> includes in MBS and you can not change this behavior for now.

Thanks for the clarification.

> Is this true for all tools that user-defined paths are searched first?
>

I have no definitive answer, but it ought to be the case otherwise  
you will never be able to override system .h files without changing  
all your code includes.  This could be potential nightmare.

> If so I can change the MBS Path calculation mechanism to add
> user-defined includes/macros first to the list.
>

Since I don't have a definitive answer it is hard to tell, but in my  
experience this would be the most sensible solution.  It turns out  
that the CDT parser actually doesn't care too much since there  the  
#define evaluator is incorrect and hence it means that the CDT often  
doesn't get the correct declarations.  I have bug fixes for this that  
I will submit as a patch soon.  Since I care a lot that the CDT  
"sees" the correct declarations I would really appreciate the local  
includes being ahead of system includes.

> As was mentioned in the
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=107952#c4, in the future
> we're going to implement a smart MBS-generic external scanner info
> provider that'll be able to calculate the precise set and order of
> includes/macros used by the tool given the environment and user- 
> defined
> option values.
>

I supposed that this was available already since there is an extended  
scanner class that enables one to build a scanner with two include  
lists (system, local) and a macro list.  So it would be great and a  
more general solution to the above.

Thanks again for the help, I'll stop smashing my head against the wall.

Jason


> Mikhail
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Jason Brown
> Sent: Tuesday, May 23, 2006 8:16 PM
> To: CDT General developers list.
> Subject: [cdt-dev] How to get CDT parser to search -I includes
> beforedefault includes
>
> Hi All,
>
> Although I have followed the discussion relating to setting options
> in managed projects for adding include paths I couldn't figure out
> how to solve the following related problem.
>
> I want user defined include paths (i.e., those added with -I by
> adding a path in tool build configuration) to come before the default
> set of include paths.  Currently the CDT parser always adds the -I
> paths afterwards.
>
> I can easily get all of the include paths for a specific resource
> from the getScannerInfoProvider(file).getIncludePaths(), however it
> is impossible to understand which are specified by -I and which by
> default.
>
> I've tried, but unsuccessfully, to get the paths via the options of a
> managed project.
>
> So, can anyone please help me either
>
> i) determine how each include path was specified (i.e., is default or
> via -I) so that I can reorder them myself or
> ii) explain how to make the -I paths always come before the default
> paths when using the CDT parser.
>
> Clear this is not a problem for the target tools as they search -I
> include paths before default paths.
>
> Any help is very much appreciated.
>
> Jason
>
> 		
> ___________________________________________________________
> Try the all-new Yahoo! Mail. "The New Version is radically easier to
> use" - The Wall Street Journal
> http://uk.docs.yahoo.com/nowyoucan.html
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev


	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and
ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev