🚀 go-pugleaf

tif@doorstop.austin.ibm.com (Paul Chamberlain) writes:

>Let's say I have source1.c, source2.c, and source3.c.  I want to
>be able to say "make exe1", "make exe2", or "make all".  But I
>want it to do the right thing if I say "make all; make all".  i.e.

>	cc -DDEF1 -c source1.c; cc -DDEF1 -c source2.c; cc -DDEF1 -c source3.c
>	cc -o exe1 source1.o source2.o source3.o
>	cc -DDEF2 -c source1.c; cc -DDEF2 -c source2.c; cc -DDEF2 -c source3.c
>	cc -o exe2 source1.o source2.o source3.o
>and then
>	`all' is up to date.

>[has 2 targets, same sources, different preprocessor definitions
>to produce different objects with the same names]

I would suggest that the object files (.o) be given different names
depending on the flags they were compiled with. Make gets confused
because it thinks that source1.o is the same as source1.o.

How about something like this:

all:	exe1 exe2

exe1:	source1.def1.o source2.def1.o source3.def1.o
	${CC} -o $@ source1.def1.o source2.def1.o source3.def1.o

exe2:	source1.def2.o source2.def2.o source3.def2.o
	${CC} -o $@ source1.def2.o source2.def2.o source3.def2.o

source1.def1.o:	source1.c
	${CC} -o source1.def1.o -DDEF1 -c $?

source2.def1.o:	source2.c
	${CC} -o source2.def1.o -DDEF1 -c $?

source3.def1.o:	source3.c
	${CC} -o source3.def1.o -DDEF1 -c $?

source1.def2.o:	source1.c
	${CC} -o source1.def2.o -DDEF2 -c $?

source2.def2.o:	source2.c
	${CC} -o source2.def2.o -DDEF2 -c $?

source3.def2.o:	source3.c
	${CC} -o source3.def2.o -DDEF2 -c $?


 ~!paul
--
Paul Ziemba  api!gpz  gpz@ESD.3com.com  408.764.5390   OS/2: just say no.

"How much char could a char star star if char star could star char?"
(quote stolen from mspercy@clemson.clemson.edu)

I wrote
>I have two executables that depend on the same source files but are
>compiled with different CFLAGS.  Anybody have a good way to make a
>makefile understand this?

Well, I got it figured out.  Below I have included a makefile for
two hypothetical executables that use the same .c's.  A fringe
benefit is that even if you only have one executable, using this
style of make file will allow you to remove all the .o's and it
still won't recompile anything unless a .c or .h changed.

Paul Chamberlain | I do NOT represent IBM.     tif@doorstop, sc30661 at ausvm6
512/838-7008     | ...!cs.utexas.edu!ibmchs!auschs!doorstop.austin.ibm.com!tif

# This is a really bizarre makefile that allows two executables to be made
# from one set of source.  In this example, the exe's are to be compiled
# with slightly different compile lines and libraries.  This should handle
# all manner of interrupted and restarted compiles.

OBJ	= obj1.o obj2.o obj3.o
HFILES	= local1.h local2.h
CFLAGS	= -O $(NAME)
LDFLAGS	= $(OTHER_LIB)

# by default, make both executables
all:	exe1 exe2

clean:
	rm -f *.o making.exe1 making.exe2

# This will prevent recompilation if everything is
# up to date even if no .o's are around.
exe1:	$(OBJ:.o=.c) exe1.c $(HFILES)
	if test ! -f making.exe1;then make clean;fi
	touch making.exe1
	$(MAKE) NAME=-DEXE1 OTHER_LIB=-lx exe1.make

exe1.make:	$(OBJ) exe1.o
	$(CC) $(CFLAGS) $(OBJ) exe1.o $(LDFLAGS) -o exe1

# This will prevent recompilation if everything is
# up to date even if no .o's are around.
exe2:	$(OBJ:.o=.c) exe2.c $(HFILES)
	if test ! -f making.exe2;then make clean;fi
	touch making.exe2
	$(MAKE) NAME=-DEXE2 exe2.make

exe2.make:	$(OBJ) exe2.o
	$(CC) $(CFLAGS) $(OBJ) exe2.o $(LDFLAGS) -o exe2

I didn't respond to original article at first since I usually don't post
but... original article stated:

>I have two executables that depend on the same source files but are
>compiled with different CFLAGS.  Anybody have a good way to make a
>makefile understand this?
>
Then he responds to his own article with...

In article <4223@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes:
>Well, I got it figured out.  Below I have included a makefile for
>two hypothetical executables that use the same .c's.  A fringe
>benefit is that even if you only have one executable, using this
>style of make file will allow you to remove all the .o's and it
>still won't recompile anything unless a .c or .h changed.
>
 <<< Complex makefile deleted >>>
  
Hmm, I am just a humble computer science student, but my Makefile for my
last project did what you said you wanted but is much more straight forward.
However, it *will* recompile missing .o files... It is below. It produces
two binaries, most of the modules are the same except for different compile
flags. Each one has a different main module.


# Makefile for least-cost communications anaylzer
# (project for Univ of Del, CIS 220 class)

CC = g++

#CFLAGS is *normal* flags for compiling program
#DFLAGS is compiled into the driver programs

CFLAGS = -O -g
DFLAGS = -DDEBUG -g

# OBJS is normal objects, DOBJS is debugging objects for driver program

OBJS = symtable.o main.o fileio.o table.o util.o
DOBJS = dsymtable.o dmain.o fileio.o dtable.o dutil.o

all: prog2 dprog2

prog2: $(OBJS)
	$(CC) $(CFLAGS) $(OBJS) -o prog2

dprog2:	$(DOBJS)
	$(CC) $(DFLAGS) $(DOBJS) -o dprog2

symtable.o: symtable.cc symtable.h general.h
	$(CC) $(CFLAGS) -c symtable.cc

table.o: table.cc table.h general.h
	$(CC) $(CFLAGS) -c table.cc

main.o: main.cc general.h symtable.h table.h util.h
	$(CC) $(CFLAGS) -c main.cc

dsymtable.o: symtable.cc symtable.h general.h
	$(CC) $(DFLAGS) -c symtable.cc -o dsymtable.o

dtable.o: table.cc table.h general.h
	$(CC) $(DFLAGS) -c table.cc -o dtable.o

dmain.o: driver.cc driver.h general.h
	$(CC) $(DFLAGS) -c driver.cc -o dmain.o

fileio.o: fileio.cc fileio.h general.h
	$(CC) $(CFLAGS) -c fileio.cc

util.o: util.cc util.h general.h fileio.h
	$(CC) $(CFLAGS) -c util.cc

dutil.o: util.cc util.h general.h fileio.h
	$(CC) $(DFLAGS) -c util.cc -o dutil.o

clean:
	rm -rf $(DOBJS) $(OBJS) prog2 dprog2 *~ core

strip:
	strip prog2 dprog2
	chmod 711 prog2 dprog2 .
	rm -rf $(OBJS) *~ core
-- 

Ken Weaverling (insert any job title here, except for official spokesperson)
Delaware Technical & Community College --- weave@brahms.udel.edu

gpz@ESD.3Com.COM (G. Paul Ziemba) writes:

>source1.def1.o:	source1.c
>	${CC} -o source1.def1.o -DDEF1 -c $?

Giving the above as an example to create a .o with a different name from the
.c it comes from.

On our system, a Bull DPX/2-340, the man page says that -o is passed to ld(1)
and this is the case when trying it. All the people I have spoken to agree
that this is what is supposed to happen in Unix C.
-- 
|Malcolm Preen          |Malcolm.Preen@hemel.bull.co.uk|
|Bull HN Info. Sys. Ltd.|HM14 UK03                     |
|Maxted Road            |Tel: +44 442 232222 x4367     |
|Hemel Hempstead, UK    |Fax: +44 442 234084           |
+-----------------------+------------------------------+
-- 
|Malcolm Preen          |Malcolm.Preen@hemel.bull.co.uk|
|Bull HN Info. Sys. Ltd.|HM14 UK03                     |
|Maxted Road            |Tel: +44 442 232222 x4367     |
|Hemel Hempstead, UK    |Fax: +44 442 234084           |
+-----------------------+------------------------------+

mpreen@hemel.bull.co.uk (Malcolm Preen) writes:
>gpz@ESD.3Com.COM (G. Paul Ziemba) writes:

>>source1.def1.o:	source1.c
>>	${CC} -o source1.def1.o -DDEF1 -c $?

>On our system, a Bull DPX/2-340, the man page says that -o is passed to ld(1)
>and this is the case when trying it. All the people I have spoken to agree
>that this is what is supposed to happen in Unix C.

Surprise, all Unixes are not alike.

It just so happens that I have a Bull DPX/2 with manuals at my
disposal, and they confirm what Mr. Preen says. I can not
determine a way to cause cc to rename the .o file.

On other Unixes I have used (BSD, Sun, Xinu), -o does in fact
specify the name of the output file regardless of the particular
compilation step being performed.

OS-dependent compiler flags are one of life's little joys
for me as a programmer attempting to build software on an
array of different platforms. I will abstain from comment
on what the "correct" cc argument syntax/semantics should
be.

 ~!paul
--
Paul Ziemba  api!gpz  gpz@ESD.3com.com  408.764.5390   OS/2: just say no.

"How much char could a char star star if char star could star char?"
(quote stolen from mspercy@clemson.clemson.edu)

In article <4196@awdprime.UUCP> tif@doorstop (Paul Chamberlain) writes:
>I have two executables that depend on the same source files but are
>compiled with different CFLAGS.  Anybody have a good way to make a
>makefile understand this?

With SunOS's make, you can simply add this line to your Makefile:

.KEEP_STATE:

This causes make to remember the exact command used to compile each object.
Since the flags are changed, make sees this as a different compile which
has not yet been done.