Re: Generic mechanism for dependencies of CPP processed files

[Ralf Wildenhues]

Hello Thomas,

* Thomas Schwinge wrote on Sat, Oct 14, 2006 at 04:49:17PM CEST:
> 
> Heh, yes, thanks for the broad hint ;-).  But it's a bit difficult and
> time-consuming to search for something when you don't know how it's
> called.

Yes.  I had that problem too, when trying to search.  ;-)
And of course somebody may remember, or speak up, in the next days.

I forgot something in my previous reply: how portable should your
approach be?  Below some comments in the light of trying to be portable
to non-GNU make (one goal for Automake code).

> On Sat, Oct 14, 2006 at 02:58:25PM +0200, Ralf Wildenhues wrote:
> > Since you seem to already have a suitable non-Automake mechanism in
> > place, would you be willing to point us to it?

> There's nothing fancy about it: just a Makefile rule that uses the usual
> GCC machinery (`-M*' options) to create a dependency file alongside the
> preprocessed file and then have the Makefile include those files. 

Are you interested in non-GCC as well?  (Since you haven't stated that
this is for HURD, I cannot know, right?  ;-)

> My problem was how to get the files included in a way that Automake
> likes.  By now I figured out that `-include not-yet-existent-file'
> works, whereas `include not-yet-existent-file' (as expected) doesn't.
> With this discovery, that problem should be solvable now (in case I
> don't decide to stay with the following setup...).

You could also go along the way that Automake dependency tracking works:
use `include' not `-include' aka. `sinclude' (actually, I don't know
which of the two latter is more portable).  Actually, even `include' is
not portable; see automake/m4/make.m4 and use @am__include@ and
@am__quote@ (both of which are internal details of Automake and may
change in the future or disappear; it's not likely, but I thought you
should know).

And then you generate stub makefile snippets at config.status time.
Just like automake/m4/depout.m4 does.  With "just like" in quotes;
that code is not really obvious IMHO.

> In the mean time I also invented the following hackery which (compared to
> the above scenery) makes (ab)use of Automake's facilities (with the
> overhead of needlessly creating a .a archive):

FYI, the mapping from source file names to object file names is also an
internal, unpublished detail.

Below is some food for thought for a *really* hacky solution, i.e., one
that very much depends on Automake internals (but in practice should
work with 1.9.6 and 1.10; again, no guarantees).  There are many open
questions (should the generated headers be distributed or not, cleaned
with `clean' or `maintainer-clean', ...).  If you don't want to generate
the AMDEP lines yourself, you can go back to thinking of duplicating
m4/depout.m4 functionality...

Cheers,
Ralf

cat >Makefile.am <<\EOF
gen_headers = d.h e.h
bin_PROGRAMS = foo
foo_SOURCES = a.c b.c c.c
nodist_foo_SOURCES = $(gen_headers)
EXTRA_DIST = d.defs e.defs
BUILT_SOURCES = $(gen_headers)
CLEANFILES = $(gen_headers)

SUFFIXES = .defs .h
.defs.h:
        $(CPP) $< >$@

if AMDEP
@am__include@ @address@hidden/$(DEPDIR)/address@hidden@
@am__include@ @address@hidden/$(DEPDIR)/address@hidden@
endif
EOF

cat >configure.ac <<\EOF
AC_INIT([deptrack], [1], [devnull])
AM_INIT_AUTOMAKE([foreign])
AC_CONFIG_FILES([Makefile])
AC_PROG_CC
AC_PROG_CPP
AC_OUTPUT
EOF