>For completeness, please remember to specify what version of GNU make
>you're using (make --version will tell you).
GNU Make version 3.79.1.
>Also, I assume that your Makefiles on HP-UX were using HP's version of
>make, not GNU make?
Yes, you are correct.
>Well, you don't show where the variables "CCC" and "CCLIBFLAGS" are
>actually set, so it's hard to diagnose the problem you're having.
CCC = g++
>Are you sure you didn't mean to set CCLIBFLAGS in the ifdef above,
>instead of CCFLAGS?
Yeah, defining CCFLAGS as CCLIBFLAGS is one of the work arounds I used. I changed it
back to ther original way for the sake of the
question. Sorry, I obviously missed one.
>From what I understand, HP-UX's make goes through the makefile using multiple passes,
>and that's why it works there and not with
gmake.
I haven't worked with gmake before and I am still confused why the GENCCFLAGS would be
used during the compile over the
CCFLAGS/CCLIBFLAGS entry in the compile line.
Thanks.
-----Original Message-----
From: Paul D. Smith [mailto:[EMAIL PROTECTED]]On Behalf Of
Paul D. Smith
Sent: Friday, March 23, 2001 11:02 AM
To: Rick Merola
Cc: [EMAIL PROTECTED]
Subject: Re: gmake issues on Linux
%% "Rick Merola" <[EMAIL PROTECTED]> writes:
Hi; please don't post HTML or Rich Text to the list; thanks. Also, if
you're going to post HTML or Rich Text, please don't hard-set the
foreground/background colors in your message: your message sets the
foreground color to black, but I use a reverse video color scheme on my
system so my background is black... hence I see what appears to be an
empty message! :). Color schemes should be the providence of the
receiver of the message, not the sender. Thanks.
rm> Here's the situation. I am porting my company's product to Linux
rm> from HP-UX. We set up generic include files define the patterns
rm> for building.
For completeness, please remember to specify what version of GNU make
you're using (make --version will tell you). Also, I assume that your
makefiles on HP-UX were using HP's version of make, not GNU make?
rm> ifdef LIB1-LINUX-NAME
rm> CCFLAGS = $(LIB1-LINUX-CCFLAGS) $(GLOBALCCLIBFLAGS)
rm> LDFLAGS = $(LIB1-LINUX-LDFLAGS) $(GLOBALLDLIBFLAGS)
rm> endif
rm> $(LIB1-LINUX-OBJDIR)/%.o: %.cc
rm> $(CCC) $(CCLIBFLAGS) -c -o $@ $<
Well, you don't show where the variables "CCC" and "CCLIBFLAGS" are
actually set, so it's hard to diagnose the problem you're having.
Are you sure you didn't mean to set CCLIBFLAGS in the ifdef above,
instead of CCFLAGS?
rm> What I have found is that when compiling, the only variable that
rm> is used is the "GENCCFLAGS", even though I use the variable to
rm> create the "LIB1-LINUX-CCFLAGS" in the Makefile. The value of
rm> "LIB1-LINUX-CCFLAGS" is set correctly, but it just isn't used.
rm> Can you tell me why?
Based on the information you provided, see above.
rm> I also found that the variables are always set to the last value
rm> set to it, not the value it is currently being set to. For
rm> example, the "LDFLAGS" used in the linking of LIB1 will be the
rm> "LDFLAGS" is not equal to "LIB1-LINUX-LDFLAGS", but to
rm> "EXE1-LINUX-LDFLAGS". I can probably fix this by renaming
rm> "LDFLAGS" to a value specific to the build I am doing, but I just
rm> want to make sure that's the way it suppose to work before I
rm> start.
Yes, this is the way it's supposed to work; it's the way _all_ versions
of make work. Other distant variants, like nmake, dmake, etc. may work
differently, of course.
You should understand how make processes makefiles to understand when
variables will be expanded immediately (so they expand to their current
value, whatever it is at that moment in the parsing of the makefile),
and when the expansion is deferred (so the value of the variable may
change to something else before it's expanded).
In particular, all variables that appear in command scripts are deferred
until the command script is run. Since no command scripts are invoked
until the entire makefile and all its included files are parsed, the
last value of a given variable that is parsed is what will be used when
it's expanded in a command script.
There's a section describing how make expands variables in the latest
GNU make manual.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
