Re: Copy files in VPATH build

[Paul Davis]

On Mon, Nov 8, 2010 at 9:14 AM, Steffen Dettmer
<address@hidden> wrote:
> On Sun, Oct 31, 2010 at 1:09 PM, Jason Curl <address@hidden> wrote:
>>>> * On Oct 30, 2010, at 5:17 PM, Jason Curl<address@hidden>  wrote:
>>>>> When building my package with "./configure" everything works well as
>>>>> some datafiles that are required for tests are in the correct place
>>>>> (my tests don't need to be installed with "make install"). However,
>>>>> when I use VPATH builds with "../configure", I don't know how to get
>>>>> my data files copied from the source to the current build path.
>
>> cpreadini:
>>   address@hidden@/cpfiles.sh @srcdir@/read.ini ./read.ini
>
> For some similar cases here we simply made some `read.ini.in' and
> used AC_CONFIG_FILES (of course requires not to have @token@ in
> the read.ini file), maybe not nice but pragmatic :)
>
> Why are the copies needed?
> Most of our tests working on input data files either create the
> files:
>
> check_PROGRAMS=readtest
> readtest_DEPENDENCIES=$(LIBDEPS) read.ini
> read.ini: Makefile
>        echo "; autogen by Makefile.am" > read.ini
>       address@hidden "[test]" >> read.ini
>       address@hidden "opt=val" >> read.ini
> CLEANFILES=read.ini
>
> (BTW, is this right?)
>
> or have something like
>
> TESTS=readtest.sh
>
> with a readtest.sh (could even be autogenerated):
>
> test -z "$srcdir" && srcdir=.
> ./readtest --ini-file=$srcdir/read.ini
>
> Is this done right and portable?
>
> oki,
>
> Steffen
>
>

That's pretty much exactly how we have things for CouchDB tests,
except that I wrote an Erlang source module that autoconf rewrites so
it knows where the build and source directories. Then in test code, I
just wrap file names with calls to source_file/1 and build_file/1 to
get the correct paths. This means that when writing tests you only
have to know if something is going to be part of the build/generated
by tests or is part of the source tarball.

I'm not exactly sure which copies you're referring to needing, but
another pattern I've seen is to just have a build target that copies
all files to the build directory so that the knowledge of paths
doesn't need to be considered. You can just treat everything as
relative to where your tests are run.

HTH,
Paul Davis