Re: [cdt-dev] Re: [Bug 51269] New: MakeTarget invokes only make builder

[Vladimir Hirsl <vhirsl@xxxxxxxxxx>]

> Bonjour Vladimir,
> 
>   Couple of points(you may have dealt with them already).
> 
> - For the include paths and symbols, some may apply to specific 
> resources and not blindly to all.
>     cc -DFOO debug.c
>     cc -DSPECIAL special.c

Yes, it is a bit of a problem. In the current plan both defines will be 
passed to both source files. In case of conflicting defines (like RELEASE 
and DEBUG) the scanner/parser will eventually get trapped. Hopefully this 
can be detected as an error in scanner configuration and appropriate 
problem marker generated with a quick fix for user to edit scanner 
configuration.
Other alternative is to manage scanner configuration on a per project 
basis which seams to be unrealistic for large projects.

> - You seem to have a lot of gcc specifics, it would be nice to push 
> that off, so it
>   could be override.  Assuming that the tools will follow POSIX 
> behaviour, is fine by
>   me (-I, -D) but there is also:
>    -Wp,<options>

Everything GNU specific will be isolated into extension point(s) so it can 
be easily implemented for other compilers.
I was not planning to consider '-Wp,option' since even gcc man page 
recommends avoiding it.

> They are still other issues, but no show-stoppers.
>   * paths, -I /cygdrive/c/home/vlad/include means nothing for 
Eclipse/java.

I am planning to use cygpath to resolve cygwin type include paths. I see a 
few issues with this myself, we'll see how it goes.

>   * Expanding of Environment, 
>    all:
>       gcc -I $$GTKHOME_INCLUDE -c gtk.c

Include paths that cannot be converted automatically to absolute or 
variable extended paths will be temporarily disabled with a problem marker 
suggesting user intervention. I know there are lot of imaginative 
constructs in makefiles and we can foresee only a few. But it would be a 
huge step if we could at least detect and report the ones that are not 
supported so that user can help the resolution. I think it is better to 
have noisy Problems view than silent parser failures (not John failures of 
course :--)).

Thanks,
Vmir