makefile and header files

[HT-Lab]

Hi All,

Not strictly a C++ question but I am sure this is a common compile issue

I have a generic makefile (see below) that I would like update such that if
I make some changes to a header file the associated cpp file is recompiled.
I tried using constructs like:

..h.cpp:
touch $<

thinking that if make detects a change in file.h it will touch file.cpp
which will then result in .cpp.o rule being executed. I tried this and some
other permutations but they all failed.

Any idea how I can fix this issue?

Thanks,
Hans.


# Specify all source
SRCS = sc_main.cpp

# Target file
TARGET = run

# Variable that points to SystemC installation path
SYSTEMC = /usr/local/systemc-2.2

INCDIR = -I. -I.. -I$(SYSTEMC)/include
LIBDIR = -L. -L.. -L$(SYSTEMC)/lib-cygwin
LIBS = -lsystemc -lm

CC = g++
CFLAGS = -g -Wno-deprecated -Wall
OBJS = $(SRCS:.cpp=.o)

EXE = $(TARGET).exe

..SUFFIXES: .cpp .o

$(EXE): $(OBJS)
$(CC) $(CFLAGS) $(INCDIR) $(LIBDIR) -o $@ $(OBJS) $(LIBS) 2>&1 | c++filt

all: $(EXE)

..cpp.o:
$(CC) $(CFLAGS) $(INCDIR) -c $<

clean:
rm -f $(OBJS) *~ $(EXE) *.bak $(TARGET).exe.stackdump

 

[Michael DOUBEZ]

HT-Lab a écrit :

Hi All,

Not strictly a C++ question but I am sure this is a common compile issue

I have a generic makefile (see below) that I would like update such that if
I make some changes to a header file the associated cpp file is recompiled.
I tried using constructs like:

.h.cpp:
touch $<

thinking that if make detects a change in file.h it will touch file.cpp
which will then result in .cpp.o rule being executed. I tried this and some
other permutations but they all failed.

Any idea how I can fix this issue?

No but if all you need is recompilation because of header change, the
usual method is to add the rule:

monobjet.o: monheader.h myheader.h meinheader.h

Using gcc, you can automatically generate dependency files through the
-M (or -MM) flags (man gcc for more info).

Michael

 

[Rui Maciel]

Hi All,

Not strictly a C++ question but I am sure this is a common compile issue


I have a generic makefile (see below) that I would like update such that
if I make some changes to a header file the associated cpp file is
recompiled. I tried using constructs like:

.h.cpp:
touch $<

thinking that if make detects a change in file.h it will touch file.cpp
which will then result in .cpp.o rule being executed. I tried this and
some other permutations but they all failed.

You don't need any complex solution to be able to do this. As I understand,
he makefile structure is basically this:

<makefile>
target: files
command
</makefile>

The target command is executed if any file in the given list is modified.
So, the only thing you have to do is include the header file as one of the
target's files. That's pretty much the very basic concept behind a
makefile: define a target, define a list of files that trigger that target
and associate a series of commands to that target.

Hope this helps
Rui Maciel

 

[Lionel B]

HT-Lab a écrit :

No but if all you need is recompilation because of header change, the
usual method is to add the rule:

monobjet.o: monheader.h myheader.h meinheader.h

Using gcc, you can automatically generate dependency files through the
-M (or -MM) flags (man gcc for more info).

If it's of interest to anyone, here's a really neat 'make' idiom that
updates dependencies "on the fly" (can't remember where I found it... I
think GNU autotools does something similar):

SRCS = ...
OBJS = $(patsubst %.cpp,%.o,$(SRCS))
DEPS = $(patsubst %.o,%.d,$(OBJS))

CFLAGS = ...

....

$(OBJS): %.o: %.cpp
$(CXX) -c -MMD -MP $(CFLAGS) $< -o $@
@sed -i -e '1s,\($*\)\.o[ :]*,\1.o $*.d: ,' $*.d

-include $(DEPS)

This creates a .d dependency file for every .o file in the same pass as
compilation (the point is you only ever need updated dependencies at the
*next* build...). The odd-looking 'sed' line makes the .d file itself
depend on relevant source and headers, while the -MP adds a 'phony'
target for all prerequisite headers to stop 'make' complaining if you
remove a header. The -include stops 'make' complaining if any .d files
are not found (eg. on initial build).

It's all pretty seamless - write once and never touch anything (pun
intended) again.

 

[Victor Bazarov]

Not strictly a C++ question but I am sure this is a common compile
issue

Nope. Many here don't even use makefiles. Resolution: add the .h
file as a dependency of your object file.

I have a generic makefile [..]

Or post to the newsgroup for your OS or your compiler.

V

 

[James Kanze]

HT-Lab a écrit :

No but if all you need is recompilation because of header change, the
usual method is to add the rule:

monobjet.o: monheader.h myheader.h meinheader.h

Using gcc, you can automatically generate dependency files through the
-M (or -MM) flags (man gcc for more info).

It's not a question of the compiler; it's a question of make (or
rather, the two together) It's almost always possible to hack
something that works, but it is rarely portable. Sun's make and
Sun CC are probably the simplest; the compiler can be told to
generate the dependencies while compiling, and a special target
in the makefile tells the makefile to use them. GNU make
documents how to build dependency files which it will use, using
compiler output from a special compiler pass; under Unix, -M is
a more or less standard way of telling the compiler to generate
dependencies (although it's -xM1 with Sun CC). There's no
guarantee that what the compiler generates will be compatible
with whatever make you're using, but they're usually close
enough that with a little help from sed...

I use GNU make exclusively, originally because make is even less
portable the C++, and GNU make is about the only one available
everywhere. And I've always managed to get it to generate
dependency files automatically. With VC++, of course, it takes
a bit more work, but the following script does the trick:

stripName () {
expr ` basename "$1" ` : '\(.*\)\.[^.][^.]*'
}

cppFlags="$1"
shift

for fn in $*
do
objectName=` stripName "${fn}" `.obj
# echo "${objectName} : ${fn}"
cl /E ${cppFlags} /Tp ${fn} |
sed -n 's:^ *# *line *[0-9]* *"\(.*\)".*:\1' |
sed 's:\\\\:/:g' |
egrep -v '/Microsoft *.*/VC/' |
egrep -v '/Program Files/' |
sort -u |
sed "s|^|${objectName} : |"
done

(Obviously, you'll have to have a Unix compatible tool kit
installed for this to work. But does anyone really use the
command interpreter which comes installed with Windows?)

 

[James Kanze]

Nope. Many here don't even use makefiles.

I agree (for once) that the question really isn't on topic (and
that it would be better asked in a group for the OS), but
seriously, does anyone really develope software without using
makefiles? (The problem is, of course, that make is not always
make. Even between two different Unixes, the makefiles often
aren't compatible, and this time, Microsoft fits right in with
Unix---their make isn't compatbile with anyone elses either.)

 

[Victor Bazarov]

I agree (for once) that the question really isn't on topic (and
that it would be better asked in a group for the OS), but
seriously, does anyone really develope software without using
makefiles? (The problem is, of course, that make is not always
make. Even between two different Unixes, the makefiles often
aren't compatible, and this time, Microsoft fits right in with
Unix---their make isn't compatbile with anyone elses either.)

Well, they do have 'NMAKE' utility, but usually when one develops
using MS Visual Studio, they don't use NMAKE, they use the 'cl'
that knows how to deal with "dsw" ("sln") and "dsp" ("vcproj")
files, which are a sort of makefile, but not really. They just
have slightly different information in them, although the purpose
is the same, essentially.

V

 

[HT-Lab]

Thanks for all replies guys,

Regards,
Hans.

Well, they do have 'NMAKE' utility, but usually when one develops
using MS Visual Studio, they don't use NMAKE, they use the 'cl'
that knows how to deal with "dsw" ("sln") and "dsp" ("vcproj")
files, which are a sort of makefile, but not really. They just
have slightly different information in them, although the purpose
is the same, essentially.

V