[cfe-users] Fwd: Re: [llvm-dev] Overriding macro values defined in source code

Sudhindra kulkarni via cfe-users cfe-users at lists.llvm.org
Fri May 10 01:52:43 PDT 2019


Hi Richard,
                     Thanks for the quick response.
I tried the -I- option.
I ran the below command
clang.exe -E path of cfile.c -I path of dir y -I-
With this I get the below error
clang.exe:error :-I- not supported , please use -iquote instead.

I tried using -iquote as well
clang.exe -E path of cfile.c -I path of dir y -iquote path of dir y

Even this did not work and it is still picking up the header file from the
same directory as that of the c file ie dir x.

I am using clang 6.0.1
Is the -I- option deprecated in clang 6.0.1?
If not is the usage of the flag(-I- and -iquote) not proper.

Thanks in advance


On May 10, 2019 1:10 PM, "Richard Smith" <richard at metafoo.co.uk> wrote:

On Thu, 9 May 2019 at 22:47, Sudhindra kulkarni
<sudhindrakkulkarni102 at gmail.com> wrote:
>
> Thanks Richard for the answer.
>
> I have another question regarding the include(-I) option.
>
> If we have a c file called cfile.c and a header file called header.h both
in the same directory say (dir x).  cfile.c includes header.h as shown below
> #include "header.h"
> And if in some other directory say (dir y)we have another header file
with the same name(header.h) but with a different content then when I try
to generate the preprocessed file using the below command,
> clang.exe -E path of cfile.c -I path of dir y
> The header.h present in the directory dir x is getting considered even
though -I points to dir y.
>
> Is this the intended behavior that the current directory is searched
first for the header files irrespective of the directory provided against
the -I option.
> If not how to make clang consider only the directories provided against
the -I option and not the current directory.

I think the only way to suppress the search in the directory of the
file containing the #include is with the -I- (dash, capital i, dash)
option. (That option also has other effects on the #include path, and
it matters where you place it relative to other -I flags.) It'd
probably be worth adding a dedicated flag for just the "don't look in
the directory containing the file" effect.

> Thanks in advance
>
>
>
>
>
>
>
> On May 9, 2019 5:01 AM, "Richard Smith" <richard at metafoo.co.uk> wrote:
>
> On Mon, 6 May 2019 at 23:09, Sudhindra kulkarni via cfe-users
> <cfe-users at lists.llvm.org> wrote:
> >
> >
> > ---------- Forwarded message ----------
> > From: "Tim Northover" <t.p.northover at gmail.com>
> > Date: May 1, 2019 3:48 PM
> > Subject: Re: [llvm-dev] Overriding macro values defined in source code
> > To: "Sudhindra kulkarni" <sudhindrakkulkarni102 at gmail.com>
> > Cc: "LLVM Developers Mailing List" <llvm-dev at lists.llvm.org>
> >
> > On Tue, 30 Apr 2019 at 22:28, Sudhindra kulkarni via llvm-dev
> > <llvm-dev at lists.llvm.org> wrote:
> > > Is it possible to override the value of AVAL through the -D option?
> > > For eg is it possible to set the value of AVAL to 2 through -D in
clang ?
> >
> > This is more a question for the cfe-users list, but as far as I know
> > there's no way to prevent redefinitions in source files.
> >
> > Cheers.
> >
> > Tim.
> >
> > Hi Team,
> >                  Consider the below C code,
> > #define AVAL 5
> > void func()
> > {
> > int a=5;
> > if(a==AVAL)
> > {
> > //Do something
> > }
> > else
> > {
> > //Do something else
> > }
> >
> > }
> > My question is
> > Is it possible to override the value of AVAL through the -D option?
> > For eg is it possible to set the value of AVAL to 2 through -D in clang
so that the else part executes?
> > Also apart from -D option we are also open to other ways of achieving
this
>
> The normal approach is to change the source to something like
>
> #ifndef AVAL
> #define AVAL 5
> #endif
>
> > Thanks in advance
> > _______________________________________________
> > cfe-users mailing list
> > cfe-users at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-users/attachments/20190510/775a198a/attachment.html>


More information about the cfe-users mailing list