make: Fatal error in reader: Badly formed macro assignment

[Seeker]

Hello,

In using Solaris Pro Compiler to compile Pro*C code. I am getting this
error:
make: Fatal error in reader: parser_proc_onl ine.mk, line 26: Badly
formed macro assignment

Based on other posts, this error is not related to C but related more
to my lack of understanding. When I look for line 26 in my make file,
it does not correlate to a MACRO assignment. Should I count blank or
comment-out lines in this measure? Any help/redirection on this point
would be appreciated.

This is the basic make command I am using:
/usr/ccs/bin/make -f parser_proc_onl ine.mk build
EXE=Parse_Algo_ Online_Attribut es.exe
OBJS=Parse_Algo _Online_Attribu tes.o

This is the make file
parser_proc_onl ine.mk
#!/bin/ksh
############### ############### ############### ############### ###########
#
# Program : parser_proc_onl ine.sh
#
# Project : ADM
#
############### ############### ############### ############### ###########
# Change Log
# Date Version Developer
Comments
############### ############### ############### ############### ###########
#
############### ############### ############### ############### ###########
# Description : This shell script runs
# 1. PRO*C Parser program
#
############### ############### ############### ############### ###########

# This makefile builds the Parser program
export ORACLE_HOME=/opt/oracle_9.2.0/precomp/lib
include /opt/oracle_9.2.0/precomp/lib/env_precomp.mk
#. /opt/oracle/product/ora920/precomp/lib/env_precomp.mk

# PARSERS is a list of the c proc Parser programs.

PARSERS= Parse_Algo_Onli ne_Attributes

# These targets build all of a class of Parser in one call to make.
parsers: $(PARSERS)

# The target 'build' puts together an executable $(EXE) from the .o
files
# in $(OBJS) and the libraries in $(PROLDLIBS). It is used to build
the
# c parser program.
# The rules to make .o files from .c and .pc files are later in this
file.
# $(PROLDLIBS) uses the client shared library; $(STATICPROLDLI BS) does
not.
#
build: $(OBJS)
$(DEMO_PROC_BUI LD_SHARED)
build_static: $(OBJS)
$(DEMO_PROC_BUI LD_STATIC)

$(PARSERS) $(OBJECT_PARSER S):
$(MAKE) -f $(MAKEFILE) OBJS=$@.o EXE=$@ build

# Some of the PARSERS require that .sql scripts be run before
precompilation.
# If you set RUNSQL=run in your call to make, then make will use
sqlplus or
# svrmgrl, as appropriate, to run the .sql scripts.
# If you leave RUNSQL unset, then make will print out a reminder to run
the
# scripts.
# If you have already run the scripts, then RUNSQL=done will omit the
reminder.
sqlplus_run:
($(CD) ../sql; $(BINHOME)sqlpl us $(USER) @$(SCRIPT) <
/dev/null)
svrmgrl_run:
($(CD) ../sql; $(BINHOME)svrmg rl < $(SCRIPT).sql)
sqlplus_ svrmgrl_:
$(SILENT)$(ECHO ) "# You must run the .sql script, " $(SCRIPT),
$(SILENT)$(ECHO ) "# before precomping this sample."
sqlplus_done svrmgrl_done:
# Here are some rules for converting .pc -> .c -> .o and for .typ ->
..h.
#
# If proc needs to find .h files, it should find the same .h files that
the
# c compiler finds. We use a macro named INCLUDE to hadle that. The
general
# format of the INCLUDE macro is
# INCLUDE= $(I_SYM)dir1 $(I_SYM)dir2 ...
#
# Normally, I_SYM=-I, for the c compiler. However, we have a special
target,
# pc1, which calls $(PROC) with various arguments, including
$(INCLUDE). It
# is used like this:
# $(MAKE) -f $(MAKEFILE) <more args to make> I_SYM=include= pc1
# This is used for some of $(PARSERS) and for $(OBJECT_PARSER S).
..SUFFIXES: .pc .c .o .typ .h

pc1:
$(PCC2C)

..pc.c:
$(MAKE) -f $(MAKEFILE) PROCFLAGS="$(PR OCFLAGS)" PCCSRC=$*
I_SYM=include= pc1

..pc.o:
$(MAKE) -f $(MAKEFILE) PROCFLAGS="$(PR OCFLAGS)" PCCSRC=$*
I_SYM=include= pc1
$(C2O)

..c.o:
$(C2O)

..typ.h:
$(OTT) intype=$*.typ hfile=$*.h outtype=$*o.typ $(OTTFLAGS)
code=c userid=$(USERID )

# These macro definitions fill in some details or override some
defaults
MAKEFILE=/opt/oracle/product/ora920/precomp/demo/proc/demo_proc.mk
OTTFLAGS=$(PCCF LAGS)
PROCPLSFLAGS=sq lcheck=semantic s userid=$(USERID )
PROCPPFLAGS=cod e=cpp $(CPLUS_SYS_INC LUDE)
PROCFLAGS=sqlch eck=semantics userid=$(USERID )
USERID=P_dm200/P_*********@edw d.world
INCLUDE=$(I_SYM ). $(I_SYM)$(PRECO MPHOME)public
$(I_SYM)$(RDBMS HOME)public $(I_SYM)$(RDBMS HOME)demo
$(I_SYM)$(PLSQL HOME)public $(I_SYM)$(NETWO RKHOME)public

[Artie Gold]

Seeker wrote:

Hello,

In using Solaris Pro Compiler to compile Pro*C code. I am getting this
error:
make: Fatal error in reader: parser_proc_onl ine.mk, line 26: Badly
formed macro assignment

Based on other posts, this error is not related to C but related more

Then why oh why are you posting here?

--ag
--
Artie Gold -- Austin, Texas
http://goldsays.blogspot.com
"You can't KISS* unless you MISS**"
[*-Keep it simple, stupid. **-Make it simple, stupid.]

[Paul Pluzhnikov]

"Seeker" <pa************ @gmail.com> writes:

Based on other posts, this error is not related to C but related more
to my lack of understanding. When I look for line 26 in my make file,
it does not correlate to a MACRO assignment.
Would you care to identify which line is line 26?
With the wrapping that google did for you, it's hard to tell.
Should I count blank or
comment-out lines in this measure?
Yes.
#!/bin/ksh
What a weird mixture. Since this is a Makefile, what is '#!/bin/ksh'
doing in here?

Looks like someone converted a shell script into a Makefile,
or someone who knows only how to write shell scripts touched it.
# This makefile builds the Parser program
export ORACLE_HOME=/opt/oracle_9.2.0/precomp/lib

My guess is that line above is line 26.
It is using "ksh" syntax, not Makefile syntax.
Remove the 'export', it doesn't belong here.

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Paul D. Smith]

%% Paul Pluzhnikov <pp************ *@charter.net> writes:

# This makefile builds the Parser program
export ORACLE_HOME=/opt/oracle_9.2.0/precomp/lib

pp> My guess is that line above is line 26. It is using "ksh" syntax,
pp> not Makefile syntax. Remove the 'export', it doesn't belong here.

Actually, that's legal in GNU make, and does just what you'd expect.

I suspect the OP is using Sun's version of make, but this makefile
contains GNU make-specific extensions and so doesn't work with Sun
make.

--
-------------------------------------------------------------------------------
Paul D. Smith <ps****@gnu.org > Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist

[Paul Pluzhnikov]

"Paul D. Smith" <ps****@gnu.org > writes:

Actually, that's legal in GNU make, and does just what you'd expect.
Yes, I knew that (but forgot :)
Of course most make variables are exported by default, so in this
case the export is redundant.
I suspect the OP is using Sun's version of make

He said so:

/usr/ccs/bin/make -f parser_proc_onl ine.mk build

Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.

[Vladimir S. Oka]

Paul Pluzhnikov wrote:

"Paul D. Smith" <ps****@gnu.org > writes:

Actually, that's legal in GNU make, and does just what you'd expect.

Yes, I knew that (but forgot :)
Of course most make variables are exported by default, so in this
case the export is redundant.

I suspect the OP is using Sun's version of make

He said so:

Now would be a good time for you all to take this off-topic discussion
somewhere topical.

--
BR, Vladimir

[Paul D. Smith]

Followups set.

%% Paul Pluzhnikov <pp************ *@charter.net> writes:

pp> Of course most make variables are exported by default, so in this
pp> case the export is redundant.

The only make variables that are exported by default are the ones that
came from the environment in the first place. This is part of the POSIX
definition of make, so it's not just GNU make that works this way.

For example, in this case the setting of ORACLE_HOME in the makefile
will only be exported if ORACLE_HOME was set in the user's environment
before make was invoked.
Cheers!

--
-------------------------------------------------------------------------------
Paul D. Smith <ps****@gnu.org > Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist

[Keith Thompson]

"Vladimir S. Oka" <no****@btopenw orld.com> writes:

Paul Pluzhnikov wrote:

"Paul D. Smith" <ps****@gnu.org > writes:

> Actually, that's legal in GNU make, and does just what you'd expect.

Yes, I knew that (but forgot :)
Of course most make variables are exported by default, so in this
case the export is redundant.

> I suspect the OP is using Sun's version of make

He said so:

Now would be a good time for you all to take this off-topic discussion
somewhere topical.

The discussion is widely cross-posted. I think Vladimir meant
specifically that it should be removed from comp.lang.c. (It probably
isn't topical on all the rest of these newsgroups either.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Vladimir S. Oka]

Keith Thompson opined:

"Vladimir S. Oka" <no****@btopenw orld.com> writes:

Paul Pluzhnikov wrote:

"Paul D. Smith" <ps****@gnu.org > writes:

> Actually, that's legal in GNU make, and does just what you'd
> expect.

Yes, I knew that (but forgot :)
Of course most make variables are exported by default, so in this
case the export is redundant.

> I suspect the OP is using Sun's version of make

He said so:

Now would be a good time for you all to take this off-topic
discussion somewhere topical.

The discussion is widely cross-posted. I think Vladimir meant
specifically that it should be removed from comp.lang.c. (It
probably isn't topical on all the rest of these newsgroups either.)

Ah, yes. My apologies. I blame it on abominable Google interface I have
to use from the office -- it doesn't show headers by default.

--
BR, Vladimir

Oatmeal raisin.