Unix Programming - Makefile again

Author

Makefile again

Otto Wyss

2004-05-13, 5:47 pm

Does anyone know why in my Makefile target "univdebug" is executed when
I want to run "make debug"? If I move the target "debug" to the botton
it's executed correct.

--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Barry Margolin

2004-05-13, 7:34 pm

In article <1gdqxli.87e91gsircwsN%otto.wyss@orpatec.ch>,
otto.wyss@orpatec.ch (Otto Wyss) wrote:

> Does anyone know why in my Makefile target "univdebug" is executed when
> I want to run "make debug"? If I move the target "debug" to the botton
> it's executed correct.

Without seeing the makefile, how are we supposed to know?

Your subject line says "again" -- was there a previous thread that we're
assumed to remember where you posted your makefile?

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Pramod Sharma

2004-05-14, 12:33 am

otto.wyss@orpatec.ch (Otto Wyss) wrote in message news:<1gdqxli.87e91gsircwsN%otto.wyss@orpatec.ch>...
> Does anyone know why in my Makefile target "univdebug" is executed when
> I want to run "make debug"? If I move the target "debug" to the botton
> it's executed correct.

Can you please send me the Makefile ?
That will make much clear to me .

Pramod Sharma

2004-05-14, 1:33 am

otto.wyss@orpatec.ch (Otto Wyss) wrote in message news:<1gdqxli.87e91gsircwsN%otto.wyss@orpatec.ch>...
> Does anyone know why in my Makefile target "univdebug" is executed when
> I want to run "make debug"? If I move the target "debug" to the botton
> it's executed correct.

Can You please send me the Makefile snippet ?
that will make me clear view.

Otto Wyss

2004-05-14, 2:34 pm

Otto Wyss <otto.wyss@orpatec.ch> wrote:

> Does anyone know why in my Makefile target "univdebug" is executed when
> I want to run "make debug"? If I move the target "debug" to the botton
> it's executed correct.

Sorry I simply forgot to append it, "make" is driving me so mad I can't
concentrate anymore.

I think I know now why, proably because of the multiple .cpp.o target.
I've now changed it so its working with ifeq's but I'd still like to
know if someone knows a better solution. The updated version can be
viewed at
"http://cvs.sf.net/viewcvs.py/wxguide/wxGuide/editor/Makefile?view=marku
p".

O. Wyss

# Purpose: makefile for wxGuide-Editor
# Created 2003-08-20

OBJ = app.o charpick.o dialogs.o edit.o filelist.o hyperlink.o prefdlg.o
prefs.o treelistctrl.o
PRG = wyoeditor

vpath %.h src
vpath %.cpp src
vpath %.h $(WXCODE)/hyperlink/include
vpath %.cpp $(WXCODE)/hyperlink/src
vpath %.h $(WXCODE)/treelistctrl/include
vpath %.cpp $(WXCODE)/treelistctrl/src

# implementation
ifneq ($(WXDEVEL),)
WXDEVEL_Debug = $(WXDEVEL)/Debug/
WXDEVEL_Univ = $(WXDEVEL)/Univ/
endif

..SUFFIXES: .o .cpp

all: $(PRG)
..cpp.o :s
g++ -c `wxgtk-2.4-config --prefix=/usr --cxxflags` `gtk-config
--cflags` -o $@ $<
$(PRG): $(OBJ)
g++ -o $(PRG) $(OBJ) -I/usr/lib/libwx_gtk_stc-2.4.a
`wxgtk-2.4-config --prefix=/usr --static --libs`

debug: $(PRG)d
..cpp.o :s
g++ -c `wxgtkd-2.4-config --prefix=/usr --cxxflags` `gtk-config
--cflags` -o $@ $<
$(PRG)d: $(OBJ)
g++ -o $(PRG)d $(OBJ) -I/usr/lib/libwx_gtk_stc-2.4
`wxgtkd-2.4-config --prefix=/usr --libs`

develdebug: $(PRG)dd
..cpp.o :s
g++ -c `$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --cxxflags`
`gtk-config --cflags` -o $@ $<
$(PRG)dd: $(OBJ)
g++ -o $(PRG)dd $(OBJ) `$(WXDEVEL_Debug)wxgtkd-2.5-config
--inplace --libs=std,stc`

univdebug: $(PRG)ud
..cpp.o :s
g++ -c `$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --cxxflags`
`gtk-config --cflags` -o $@ $<
$(PRG)ud: $(OBJ)
g++ -o $(PRG)ud $(OBJ) `$(WXDEVEL_Debug)wxgtkd-2.5-config
--inplace --libs=std,stc`

clean:
rm -f *.o
--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Jens.Toerring@physik.fu-berlin.de

2004-05-16, 11:34 am

Otto Wyss <otto.wyss@orpatec.ch> wrote:
> Otto Wyss <otto.wyss@orpatec.ch> wrote:

[vbcol=seagreen]
> Sorry I simply forgot to append it, "make" is driving me so mad I can't
> concentrate anymore.

> I think I know now why, proably because of the multiple .cpp.o target.
> I've now changed it so its working with ifeq's but I'd still like to
> know if someone knows a better solution. The updated version can be
> viewed at
> "http://cvs.sf.net/viewcvs.py/wxguide/wxGuide/editor/Makefile?view=marku
> p".

> O. Wyss

> # Purpose: makefile for wxGuide-Editor
> # Created 2003-08-20

> OBJ = app.o charpick.o dialogs.o edit.o filelist.o hyperlink.o prefdlg.o
> prefs.o treelistctrl.o
> PRG = wyoeditor

> vpath %.h src
> vpath %.cpp src
> vpath %.h $(WXCODE)/hyperlink/include
> vpath %.cpp $(WXCODE)/hyperlink/src
> vpath %.h $(WXCODE)/treelistctrl/include
> vpath %.cpp $(WXCODE)/treelistctrl/src

> # implementation
> ifneq ($(WXDEVEL),)
> WXDEVEL_Debug = $(WXDEVEL)/Debug/
> WXDEVEL_Univ = $(WXDEVEL)/Univ/
> endif

> .SUFFIXES: .o .cpp

> all: $(PRG)
> .cpp.o :s
> g++ -c `wxgtk-2.4-config --prefix=/usr --cxxflags` `gtk-config
> --cflags` -o $@ $<
> $(PRG): $(OBJ)
> g++ -o $(PRG) $(OBJ) -I/usr/lib/libwx_gtk_stc-2.4.a
> `wxgtk-2.4-config --prefix=/usr --static --libs`

> debug: $(PRG)d
> .cpp.o :s
> g++ -c `wxgtkd-2.4-config --prefix=/usr --cxxflags` `gtk-config
> --cflags` -o $@ $<
> $(PRG)d: $(OBJ)
> g++ -o $(PRG)d $(OBJ) -I/usr/lib/libwx_gtk_stc-2.4
> `wxgtkd-2.4-config --prefix=/usr --libs`

> develdebug: $(PRG)dd
> .cpp.o :s
> g++ -c `$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --cxxflags`
> `gtk-config --cflags` -o $@ $<
> $(PRG)dd: $(OBJ)
> g++ -o $(PRG)dd $(OBJ) `$(WXDEVEL_Debug)wxgtkd-2.5-config
> --inplace --libs=std,stc`

> univdebug: $(PRG)ud
> .cpp.o :s
> g++ -c `$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --cxxflags`
> `gtk-config --cflags` -o $@ $<
> $(PRG)ud: $(OBJ)
> g++ -o $(PRG)ud $(OBJ) `$(WXDEVEL_Debug)wxgtkd-2.5-config
> --inplace --libs=std,stc`

> clean:
> rm -f *.o

I really don't understand much of what you're doing here, so take what-
ever I write not too seriously. But some things look a bit fishy. First
of all a short bit copied from the make manual:

Suffix rules cannot have any prerequisites of their own. If they
have any, they are treated as normal files with funny names, not as
suffix rules. Thus, the rule:

.c.o: foo.h
$(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $<

tells how to make the file `.c.o' from the prerequisite file `foo.h',

I guess that means that lines like

> .cpp.o :s

are treated that way. But I don't know what 's' is, is that the name of
an existing file?

Second when I do

jens@john:~/TESTS> make -k -f owmake debug
owmake:32: warning: overriding commands for target `.cpp.o'
owmake:25: warning: ignoring old commands for target `.cpp.o'
owmake:39: warning: overriding commands for target `.cpp.o'
owmake:32: warning: ignoring old commands for target `.cpp.o'
owmake:46: warning: overriding commands for target `.cpp.o'
owmake:39: warning: ignoring old commands for target `.cpp.o'
....

That looks as if only the last of your ".cpp.o" rules is used, giving
you the impression as if 'univdebug:' is invoked, while in reality
only the the ".cpp.o" rule in that target is used because it's the
last defined (and with moving the 'debug:' target to the end it works
because then its ".cpp.o" rule is the last). I don't think that you
can have more than a single suffix rule in a makefile.

I have a feeling that all that comes from a slight misconception
about the way makefiles work. You seem to look at the different
targets as unrelated sections of the file and assume that the one
you specify on the command line is going to be used exclussively
while all others are completly disregarded. I fear that's not the
way it works. If that's what you want it probably would be easier
to create several makefile and execute them from the targets. I.e.
use

debug: $(PRG)d
$(MAKE) -f debug_makefile

univdebug: $(PRG)ud
$(MAKE) -f univdebug_makefile

and create another file, named debug_makefile, where you have
the suffix rule

..cpp.o :s
g++ -c `wxgtkd-2.4-config --prefix=/usr --cxxflags` `gtk-config--cflags` -o $@ $<

and a file, named univdebug, with

..cpp.o :s
g++ -c `$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --cxxflags` `gtk-config --cflags` -o $@ $<

All you then may need is a line with the word 'export' before the first
target, so that the other makefiles get the values of all the variables
you defined.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de

Jens.Toerring@physik.fu-berlin.de

2004-05-16, 12:34 pm

Jens.Toerring@physik.fu-berlin.de wrote:
Sorry for following-up to myself, but...

> ever I write not too seriously. But some things look a bit fishy. First
> of all a short bit copied from the make manual:

To be precise, the GNU make manual.

> Second when I do
> jens@john:~/TESTS> make -k -f owmake debug

I forget to mention that I named your makefile 'owmake' since I also
have another file called 'Makefile' in that directory.

Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de

Otto Wyss

2004-05-16, 5:34 pm

<Jens.Toerring@physik.fu-berlin.de> wrote:
> I have a feeling that all that comes from a slight misconception
> about the way makefiles work. You seem to look at the different
> targets as unrelated sections of the file and assume that the one
> you specify on the command line is going to be used exclussively
> while all others are completly disregarded. I fear that's not the
> way it works. If that's what you want it probably would be easier
> to create several makefile and execute them from the targets. I.e.
> use
>
Maybe that's the problem. Anyway it's better to look once at the current
version. I added comments in the Makefile (just here in the mail) so you
might understand my reasoning.

I try to achieve a Makefile where just the top lines "OBJ" and "PRG"
need to be changed for any of my apps. Besides the libraries and the
vpath this holds true. While the vpath is also located at the top I
haven't found a solution for the libraries.

I also try to achieve a Makefile which can be used by anyone else
building my apps (with installed wxWidgets).

########################################
###################
# Here I want to list all the items which have to be build.
OBJ = app.o charpick.o dialogs.o edit.o filelist.o hyperlink.o prefdlg.o
prefs.o treelistctrl.o

# The name for the executable
PRG = wyoeditor

# All sources and headers are located in subdir src
vpath %.h src
vpath %.cpp src

# The module hyperlink and treelistctrl (source and header) from wxCode
# are needed.
# The environment variable WXCODE contains the path to wxCode but so
# far this doesn't work. I don't know why the aren't included.
vpath %.h $(WXCODE)/hyperlink/include
vpath %.cpp $(WXCODE)/hyperlink/src
vpath %.h $(WXCODE)/treelistctrl/include
vpath %.cpp $(WXCODE)/treelistctrl/src

# In case of development the headers/libs from the development sections
# should be used and have to be set. Otherwise the standard paths are
# used.
ifneq ($(WXDEVEL),)
WXDEVEL_Release = $(WXDEVEL)/Release/
WXDEVEL_Debug = $(WXDEVEL)/Debug/
WXDEVEL_Univ = $(WXDEVEL)/Univ/
endif

# For each target a different wx-config is needed but since the
# .cpp.o needs this as well the following selections has to be made.
# I'd prefer if they wouldn't be necessary and could be set by the
# targets. Therefore I tried to move .cpp.o into all targets which
# is obviously wrong.
ifeq ($(MAKECMDGOALS),)
WXCONFIG=wxgtk-2.4-config --prefix=/usr
endif
ifeq ($(MAKECMDGOALS),debug)
WXCONFIG=wxgtkd-2.4-config --prefix=/usr
endif
ifeq ($(MAKECMDGOALS),develdebug)
WXCONFIG=$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace
endif
ifeq ($(MAKECMDGOALS),univdebug)
WXCONFIG=$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace
endif

# I don't understand this exactly but it seems to be needed
..SUFFIXES: .o .cpp

# Compilation of each source according to wx-config selection
# I don't know what "s" stands for, also I don't understand "$@ $<"
..cpp.o :s
g++ -c `$(WXCONFIG) --cxxflags` `gtk-config --cflags` -o $@ $<

# All the targets as I understand them. Besides the library inclusion
# any of my application will have the same targets below
all: $(PRG)
$(PRG): $(OBJ)
g++ -o $(PRG) $(OBJ) -l/usr/lib/libwx_gtk_stc-2.4.a `$(WXCONFIG)
--static --libs`

debug: $(PRG)d
$(PRG)d: $(OBJ)
g++ -o $(PRG)d $(OBJ) -lwx_gtkd_stc-2.4 `$(WXCONFIG) --libs`

develdebug: $(PRG)dd
$(PRG)dd: $(OBJ)
g++ -o $(PRG)dd $(OBJ) -lwx_gtkd_stc-2.5 `$(WXCONFIG) --libs`

univdebug: $(PRG)ud
$(PRG)ud: $(OBJ)
g++ -o $(PRG)ud $(OBJ) -lwx_gtkd_stc-2.5 `$(WXCONFIG) --libs`

# cleanup, removing everything whats made except for the executables.
# Maybe I should remove the as well but during development it's so
# convenient to keep them.
clean:
rm -f *.o
########################################
###################

O. Wyss

--
See a huge pile of work at "http://wyodesktop.sourceforge.net/"

Jens.Toerring@physik.fu-berlin.de

2004-05-16, 7:34 pm

Otto Wyss <otto.wyss@orpatec.ch> wrote:
> I try to achieve a Makefile where just the top lines "OBJ" and "PRG"
> need to be changed for any of my apps. Besides the libraries and the
> vpath this holds true. While the vpath is also located at the top I
> haven't found a solution for the libraries.

> I also try to achieve a Makefile which can be used by anyone else
> building my apps (with installed wxWidgets).

> ########################################
###################
> # Here I want to list all the items which have to be build.
> OBJ = app.o charpick.o dialogs.o edit.o filelist.o hyperlink.o prefdlg.o
> prefs.o treelistctrl.o

Maybe it would be even nicer to have the list of all source files

SRC = = app.cpp charpick.cpp dialogs.cpp edit.cpp filelist.cpp \
hyperlink.cpp refdlg.cpp prefs.cpp treelistctrl.cpp

or even

SRC = $(wildcard *.cpp)

if you always want all .cpp files (but then probably must move this
to a point after setting up vpath) and then create the list of objects
automatically from this list

OBJ = $(SRC:.cpp=.o)

> # The name for the executable
> PRG = wyoeditor

> # All sources and headers are located in subdir src
> vpath %.h src
> vpath %.cpp src

> # The module hyperlink and treelistctrl (source and header) from wxCode
> # are needed.
> # The environment variable WXCODE contains the path to wxCode but so
> # far this doesn't work. I don't know why the aren't included.
> vpath %.h $(WXCODE)/hyperlink/include
> vpath %.cpp $(WXCODE)/hyperlink/src
> vpath %.h $(WXCODE)/treelistctrl/include
> vpath %.cpp $(WXCODE)/treelistctrl/src

I must admit that I never used vpath, but I am having the feeling that
when you first use

vpath %.cpp src

and then

vpath %.cpp $(WXCODE)/hyperlink/src

the second setting would overwrite the first. Perhaps you should try

vpath %.cpp src:$(WXCODE)/hyperlink/src:$(WXCODE)/treelistctrl/src

(as far as I understand it from a short look at the explanation for vpath
you can assemble a list of directories by appending all of them with a
colon in between, like in environment variables).

> # In case of development the headers/libs from the development sections
> # should be used and have to be set. Otherwise the standard paths are
> # used.
> ifneq ($(WXDEVEL),)
> WXDEVEL_Release = $(WXDEVEL)/Release/
> WXDEVEL_Debug = $(WXDEVEL)/Debug/
> WXDEVEL_Univ = $(WXDEVEL)/Univ/
> endif

> # For each target a different wx-config is needed but since the
> # .cpp.o needs this as well the following selections has to be made.
> # I'd prefer if they wouldn't be necessary and could be set by the
> # targets. Therefore I tried to move .cpp.o into all targets which
> # is obviously wrong.

I guess there's no other way (at least I don't see one ATM) when you
insist on sticking with the way you do it now. But see below for an
alternative...

> ifeq ($(MAKECMDGOALS),)
> WXCONFIG=wxgtk-2.4-config --prefix=/usr
> endif
> ifeq ($(MAKECMDGOALS),debug)
> WXCONFIG=wxgtkd-2.4-config --prefix=/usr
> endif
> ifeq ($(MAKECMDGOALS),develdebug)
> WXCONFIG=$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace
> endif
> ifeq ($(MAKECMDGOALS),univdebug)
> WXCONFIG=$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace
> endif

> # I don't understand this exactly but it seems to be needed
> .SUFFIXES: .o .cpp

That tells make that you're going to replace the implicit suffix
rules by with make would create missing .o and .cpp files. Since
you don't seem to require creation of .cpp files I guess you can
drop the '.cpp' here. But I am not sure if you need this at all.

> # Compilation of each source according to wx-config selection
> # I don't know what "s" stands for, also I don't understand "$@ $<"

> .cpp.o :s
> g++ -c `$(WXCONFIG) --cxxflags` `gtk-config --cflags` -o $@ $<

What happens if you use just ".cpp.o:"? To me that would look more
reasonable, given how I understand the GNU make manual, which I would
tend to understand that the above states how to make a file named
".cpp.o" (that's the complete file name!) from an input file named 's'.
And, since such a file is never required, that rule never should
be used, and make falling back to its built-in rule how to make
a .o file from a .cpp file. But, on the other hand, I never used
the old-fashioned suffix rules... But I would try just

..cpp.o:
g++ -c `$(WXCONFIG) --cxxflags` `gtk-config --cflags` -o $@ $<

The "$@" and "$<" are special make variables. "$@" automatically gets
replaces by the target, i.e. what needs to be made by the rule.
Here it's the name of the ".o" file to be created. "$<" is the name of
the first prerequisite, i.e. the first file the target is to be made
from. You can use that here because there's only a single prerequisite,
the .cpp file the .o file is created from. When you run make it will
find that it e.g. needs the file "app.o" (since that is required for
all the final targets, at least if it doesn't exist or "app.cpp" is
newer than "app.o") and it should then run the command

g++ -c g++ -c `$(WXCONFIG) --cxxflags` `gtk-config --cflags` -o app.o app.cpp

There are some more useful variables like these. For example, there's
"$^", which is a list of all prerequisites (with spaces between them)
and files listed in the prerequisites more than once listed only
once.

> # All the targets as I understand them. Besides the library inclusion
> # any of my application will have the same targets below

> all: $(PRG)
> $(PRG): $(OBJ)
> g++ -o $(PRG) $(OBJ) -l/usr/lib/libwx_gtk_stc-2.4.a `$(WXCONFIG)
> --static --libs`

You could also write this, using makes funny variables as

$(PRG): $(OBJ)
g++ -o $@ $^ -l/usr/lib/libwx_gtk_stc-2.4.a `$(WXCONFIG) --static --libs`

A somewhat different approach (that would get rid of the #ifeq/#endif
stuff you seem to be unhappy with) would be to make the extensions of
the object files differ depending on the mode you're compiling in and
not just the final programs. You could do something like this:

all:
$(MAKE) $(PROG)

$(PRG): $(OBJ)
g++ -o $@ $^ -l/usr/lib/libwx_gtk_stc-2.4.a \
`wxgtk-2.4-config --prefix=/usr --static --libs`

..cpp.o:
g++ -c `wxgtk-2.4-config --prefix=/usr --cxxflags` \
`gtk-config --cflags` -o $@ $<

debug:
$(MAKE) $(PROG)d

$(PROG)d: $(patsubst %.o,%.od,$(OBJ))
g++ -o $@ $^ -lwx_gtkd_stc-2.4 `wxgtkd-2.4-config --prefix=/usr --libs`

..cpp.od:
g++ -c `wxgtk-2.4-config --prefix=/usr --cxxflags` \
`gtk-config --cflags` -o $@ $<

develdebug:
$(MAKE) $(PROG)dd

$(PROG)dd: $(patsubst %.o,%.odd,$(OBJ))
g++ -o $@ $^ -lwx_gtkd_stc-2.5 \
`$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --libs`

..cpp.odd:
g++ -c `wxgtk-2.4-config --prefix=/usr --cxxflags` \
`$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --cflags` -o $@ $<

univdebug:
$(MAKE) $(PROG)ud

$(PROG)ud: $(patsubst %.o,%.oud,$(OBJ))
g++ -o $@ $^ -lwx_gtkd_stc-2.5 \
`$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --libs`

..cpp.oud:
g++ -c `wxgtk-2.5-config --prefix=/usr --cxxflags` \
`$(WXDEVEL_Debug)wxgtkd-2.5-config --inplace --cflags` -o $@ $<

That should work because the compiler couldn't care less about what kind
of extension its output file has, and also the linker isn't picky when
you tell it what to use (but then you definitely have to use the dreaded
"$^" variable;-) And you can build everything in all versions at the
same time without always overwriting the already existing .o files (that
actually may not even get created anew when you switch from e.g. target
'all' to target 'debug' since the .cpp files haven't changed in the mean
time). But take care, you have to look again carefully that I got all the
replacements right, you know much better what's needed where...

Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de

Paul D. Smith

2004-05-30, 10:29 am

%% Jens.Toerring@physik.fu-berlin.de writes:
[vbcol=seagreen]
[vbcol=seagreen]

jt> Thanks for pointing that out. But which of the rules are then picked
jt> when there is more than one?

Not sure what you mean. More than one what? There can only be one
suffix rule for any given pair of target/prerequisite suffixes. If you
define another one, the first one is replaced with the new definition.
If you mean rules with the same target suffix but different prerequisite
suffixes, then they are tried in order of definition.

--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@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

Jens.Toerring@physik.fu-berlin.de

2004-05-30, 10:29 am

Paul D. Smith <psmith@gnu.org> wrote:
> %% Jens.Toerring@physik.fu-berlin.de writes:

[vbcol=seagreen]
[vbcol=seagreen]
> jt> Thanks for pointing that out. But which of the rules are then picked
> jt> when there is more than one?

> Not sure what you mean. More than one what? There can only be one
> suffix rule for any given pair of target/prerequisite suffixes. If you
> define another one, the first one is replaced with the new definition.
> If you mean rules with the same target suffix but different prerequisite
> suffixes, then they are tried in order of definition.

Thanks. I guess I misunderstood you but now I think it's perfectly
clear.
Regards, Jens

--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de