[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Re: [Bug 51269] New: MakeTarget invokes only make builder
|
> 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