automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Disable implicit RCS rule of GNU Make


From: Robert Homann
Subject: Disable implicit RCS rule of GNU Make
Date: Mon, 19 Jun 2006 19:32:29 +0200 (MEST)

Hello list!

We have a problem here with GNU Make's built-in rules that I can't seem to
be able to solve. Short version of my question: How can the implicit rule
for RCS defined in GNU Make be disabled in a portable way (Automake 1.9.6,
Autoconf 2.59)? Using GNU Make syntax, this can be done using

% : RCS/%,v
% : %,v

but this is not portable to non-GNU Make implementations. Automake throws
warnings about these when invoked via `autoreconf -s -i'. Is there a good
solution to this problem?


Longer version of my question: We are using RCS (Revision Control System)
to maintain our sources. In RCS, any file under version control is usually
stored in a subdirectory of the file's directory, "RCS/", with all its
version history inside and a ",v" tacked to its end (such that for
"helloworld.c" there is also a versioned file "RCS/helloworld.c,v"). Files
can be checked in and out using commands "ci" and "co", respectively.
Unfortunately, for several reasons, we cannot switch to something better
than RCS, like Subversion, right now and we are stuck with RCS for at
least a while.

Our problem is that GNU Make has an implicit rule for this to automatically
check out files for which a corresponding ",v" file exists, in the current
or RCS directory. Now, in a VPATH build, source files are checked out
automatically from $(srcdir)/RCS/ to $(builddir) by that implicit rule,
even if they have been checked out before to $(srcdir) by the user. This
is really bad because once a file has been checked out to $(builddir) by
Make, any changes to the working copy in $(srcdir) go unnoticed since Make
sees only the unchanged file in $(builddir). Seems like Automake doesn't
know of that annoying implicit rule in GNU Make, which I think is
perfectly OK, and hence doesn't introduce dependencies that would trigger
a rebuild. Consequently, `make clean' also doesn't remove the checked out
files in $(builddir).

I tested with a small test case, consisting of minimalistic configure.ac,
Makefile.am, and helloworld.c. Then I created a directory "RCS" and checked
in helloworld.c using "ci -u helloworld.c" (the -u tells ci to not delete
helloworld.c after checking in), and tried desperately...

configure.ac:
-----
AC_PREREQ(2.59)
AC_INIT([RCStest],[1.0],[rhomann.AT.techfak.uni-bielefeld.de],[RCStest])
AM_INIT_AUTOMAKE([-Wall foreign])
AC_CONFIG_SRCDIR([helloworld.c])
AC_CONFIG_HEADER([config.h])
AC_PROG_CC
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
-----

Makefile.am:
-----
bin_PROGRAMS=helloworld
helloworld_SOURCES=helloworld.c
-----

$ autoreconf -s -i
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
Makefile.am: installing `./depcomp'


All Make implementations I have access to work fine with the Makefiles
generated by Automake 1.9.6 and Autoconf 2.59 using the files shown above,
only GNU Make exhibits the undesired behavior described before. Appending
the two lines

% : RCS/%,v
% : %,v

to Makefile.am results into

$ autoreconf -s -i
configure.ac: installing `./install-sh'
configure.ac: installing `./missing'
Makefile.am:3: `%'-style pattern rules are a GNU make extension
Makefile.am:4: `%'-style pattern rules are a GNU make extension
Makefile.am: installing `./depcomp'


So I end up with two warnings and one non-portable Makefile. The Make
implementations I have access to are fine with these rules, though, only
smake 1.2a23 on Ubuntu 5.10 crashed with a segfault if these rules were
present (commenting them out in the generated Makefile made smake pass).

Instead, because the GNU Make manual states that `$(CO) $(COFLAGS)' is the
command used to check out sources, I also tried the line

CO = \#

in Automake.am, with minor success. For GNU Make, this resulted in:

make  all-am
make[1]: Entering directory 
`/amnt/callisto/users/pistaff01/pistaff/rhomann/automake_testing_obj'
#  ../automake_testing/RCS/helloworld.c,v helloworld.c
if gcc -DHAVE_CONFIG_H -I. -I../automake_testing -I.     -g -O2 -MT 
helloworld.o -MD -MP -MF ".deps/helloworld.Tpo" -c -o helloworld.o 
helloworld.c; \
then mv -f ".deps/helloworld.Tpo" ".deps/helloworld.Po"; else rm -f 
".deps/helloworld.Tpo"; exit 1; fi
gcc: helloworld.c: No such file or directory
gcc: no input files
make[1]: *** [helloworld.o] Error 1
make[1]: Leaving directory 
`/amnt/callisto/users/pistaff01/pistaff/rhomann/automake_testing_obj'
make: *** [all] Error 2


Here the CO command has been turned into a comment so nothing got checked
out, but the compiler didn't get the full path to the real helloworld.c in
$(srcdir), which would have been ../automake_testing/helloworld.c in this
case.

So, how can I disable the implicit RCS rule in a portable way? Is using
an AM_CONDITIONAL in configure.ac to decide between GNU/non-GNU Make the
way to go? Or is there a better solution that works with all Make
implementations without the help of Autoconf, which is what I would prefer
(because we include Automake snippets in Makefile.am files for this in
multiple projects and wouldn't need to touch our configure.ac files then)?

Sorry for putting short questions into long words... :)

bye, Robert

-- 
Windows is not the answer.
Windows is the question.
The answer is "No".




reply via email to

[Prev in Thread] Current Thread [Next in Thread]