Re: make distcheck not finding custom code generation script

[Brian Dessent]

Andreas Ntaflos wrote:

> So to translate foo.ice to foo.cc and
> foo.hh I need to run (in my $(topdir)/src subdirectory)
> 
> ../tools/wrapper.sh /path/to/foo2cpp foo.ice
> 
> In src/Makefile.am there is a target that does just that:
> 
> foo.cc foo.hh: foo.ice
>         $(ICE_FOO2CPP) foo.ice
> [...]
>
> make[1]: Entering directory `/path/to/foo_project/foo-1.0/_build'
> make  all-recursive
> make[2]: Entering directory `/path/to/foo_project/foo-1.0/_build'
> Making all in src
> make[3]: Entering directory `/path/to/foo_project/foo-1.0/_build/src'
> ../tools/wrapper.sh /usr/bin/foo2cpp foo.ice
> make[3]: ../tools/wrapper.sh: Command not found
> 
> Which is correct, there is no wrapper.sh script from where make
> distcheck is looking (i.e. from
> inside /path/to/foo_project/foo-1.0/_build/src). Also there are no

Among the things that 'distcheck' checks is whether building in a
directory outside of the source directory (sometimes referred to as a
"VPATH build") works.  This is a convenient and important feature to
support, as many developers and users expect for this to work --
especially since you typically get this functionality for free without
having to do anything explicit if you use automake.

One might want to use a VPATH build because it keeps all of the built
files in a different tree from the source files, which generally is very
tidy since you can just "rm -rf" this dir and get back to the initial
pristine state, without having to use "make distclean" which can take
longer (and in some cases requires a bunch of needless work like
rerunning configure.)

It also allows for having multiple builds from the same source tree
(such as an optimized build and a debug build) without having to copy
any source files around.  And it allows for the source files to be on a
remote read-only NFS mount, with built files stored locally, a situation
which some organizations use for build farms or other such
automated/distributed setups.

So the answer to your question is that you shouldn't assume that you are
in the source tree when referring to files.  Try having your macro
expand the path as "$(srcdir)/tools/wrapper.sh" instead of
"../tools/wrapper.sh".  I'm not entirely sure of the correct quoting
here, but I'm pretty sure you want it to expand as $(srcdir) in the
final generated Makefile rule, so this might involve quoting the ('s and
)'s in m4, I don't know.

Brian