help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ifeq problem


From: Tom Rosmond
Subject: Re: ifeq problem
Date: Sun, 18 Dec 2011 14:16:49 -0800

Paul,

OK, the solution is, of course, trivial.  This works:

HOST = fir

all:
ifeq ($(HOST),cedar)
        @echo $(HOST)
else
        @echo 'nothost'
endif

where the 'echo' lines need tabs, but the conditional parts do not.

Thanks,

T. Rosmond



On Sun, 2011-12-18 at 16:44 -0500, Paul Smith wrote:
> Hi Tom; please keep these discussions on the list, thanks!
> 
> On Sun, 2011-12-18 at 12:40 -0800, Tom Rosmond wrote:
> > I have been writing makefile for a long time, and although I am
> > certainly not an expert, I thought I knew what I was doing.  However, I
> > haven't used the conditional concept very much, so I have more to learn.
> 
> The thing to keep clearly in mind is which statements are makefile
> statements (variable assignments, rule declarations, and GNU make
> preprocessor statements like export, ifeq/ifneq/ifdef, define, etc.
> etc.) and which are shell statements.
> 
> All makefile statements CANNOT be prefixed with a TAB [*], and all shell
> statements MUST be prefixed by a TAB.
> 
> > If I remove the tabs, I get the familiar 'missing separator' message,
> > which usually means tabs are missing from the rule.  This seems like a
> > catch22.  I'd appreciate any suggestions on making this work.
> 
> > > > all:
> > > >         ifeq ($(HOST),cedar)
> > > >         @echo $(HOST)
> > > >         endif
> 
> Please provide the specific example which shows the "missing separator"
> message when you run it.
> 
> If you remove the TABs from the makefile statements then you will not
> see that message, so you are doing something else here; without seeing
> what you did we can't comment on what might be wrong.
> 
> Cheers!
> 
> 
> [*] It's not technically true that makefile statements cannot be
>     prefixed by a TAB; GNU make actually only treats TAB-indented
>     lines as shell lines if they appear in a "rule context"; but it's
>     much simpler to use the general rule and not rely on the special
>     cases.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]