Kemp@dockmaster.ncsc.mil (06/27/89)
After watching the "make wars" on info-unix between GNU make and AT&T
toolchest make, I am convinced that we Sun users have a pretty good
product that has lots of good features that were added without breaking
compatibility or introducing lots of bugs.
That said, there is one thing I haven't been able to figure out from the
examples in the manual. I want to do the equivalent of:
if(sun3) CFLAGS = -f68881
else CFLAGS = (nothing)
A conditional macro seems to be the way to do it, but the syntax is
target-list := macro = value
i.e. the assignment is conditioned on the target, not on the value of
another macro (TARGET_ARCH). There is probably a gross solution like
defining identical targets PROGRAM.sun3 and PROGRAM.sun4, but an elegant
solution would be better.
I finally gave up and used a pattern replacement hack. Here is the
Makefile:
--------------
SOURCES= prog.c sub.c
ULIBS= ../lib/$(ARCH)/lib.a
PROGRAM= prog
CFLAGS= -O3 $(TARGET_ARCH:-sun3=-f68881) <<< Gross Hack!!!
OBJECTS= $(SOURCES:.c=.o)
ARCH= $(TARGET_ARCH:-%=%)
all debug profile: $(PROGRAM)
debug := CFLAGS= -g <<< This is where it should
profile := CFLAGS= -pg -O3 <<< really be done
$(PROGRAM): $(OBJECTS)
$(LINK.c) -o $@ $(OBJECTS) $(ULIBS)
---------------
This works for a sun3, (when not doing a make debug or profile), but on a
sun4 it gives an ugly but apparently harmless duplicate flag:
cc -O3 -sun4 -sun4 -c prog.c
It would not work in the general case of more than two alternatives (like
if I gave a hoot about -sun386i) or if the macro must have different
values for each alternative (i.e. the unmodified value -sun4 is not
acceptable). Surely this is an extremely common situation; I'm surprised
that Sun's otherwise good make manual has absolutely no examples of
variants depending on TARGET_ARCH.
If you have a concise, sophisticated solution, please mail it to me; I
will summarize for the group.
Dave Kemp <Kemp@dockmaster.ncsc.mil>gary@svx.sv.dg.com (07/12/89)
In article <4226@kalliope.rice.edu> Kemp@dockmaster.ncsc.mil writes: >X-Sun-Spots-Digest: Volume 8, Issue 60, message 4 of 7 >After watching the "make wars" on info-unix between GNU make and AT&T >toolchest make, I am convinced that we Sun users have a pretty good >product that has lots of good features that were added without breaking >compatibility or introducing lots of bugs. Until you try to port, e.g., xtroff to your 4.0.x system and discover that make got broken in 4.x for targets with 2 or more "."s in the name. Having just tried to explain "yacc stack overflow" while porting c++ to the Sun software rep, I can't wait to try this one on them --- "Could you send us an example of the code that causes the yacc stack overflow?" "Why?" ... "Could you send us some targets with multiple "."s in them..." -- Gary Bridgewater, Data General Corp., Sunnyvale Ca. gary@sv4.ceo.sv.dg.com or {amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary No good deed goes unpunished.
Kemp@dockmaster.ncsc.mil (Dave Kemp) (07/15/89)
Recently I asked how to do: > if (sun3) CFLAGS = -f68881 > else CFLAGS = (nothing) > . . . I will summarize for the group. Thanks for all the suggestions. Dieter Woerz ({pyramid!iaoobel,uunet!unido}!isaak!woerz) suggested using imake, which modifies a makefile, passes it through cpp, and give the result to make. He mentions that the X distribution is built using imake, and that it is available with X in the directory util/imake. Larry Weissman (larryw@nsr.bioeng.washington.edu) suggests using make recursively, with the outer call checking the status of /bin/sun3 and then invoking make with CFLAGS set explicitly on the command line: $(MAKE) "CFLAGS=$(SUN3CFLAGS)", where SUN3CFLAGS is set up earlier, and an "if" test is used to terminate the recursion. David@sun.com had the best suggestion, being both concise and quite general. It involves using nested macro expansion to generate the name of the macro to use for each particular case. Here it is, in its entirety: CFLAGS= $(CFLAGS$(TARGET_ARCH)) CFLAGS-sun3= -f68881 David credits the author of make for this idea; the technique is so generally useful that it is now a permanent part of my bag of tricks. Thanks again to everyone who responded. Dave Kemp <Kemp@dockmaster.ncsc.mil>