On Dec 2, 2013, at 8:49 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes:
>
>> There reason for TESTEXAMPLES_C TESTEXAMPLES_etc is that make
>> doesn’t have if tests. Since we have shifted to gnumake can we
>> eliminate all these variables and handle the cases with appropriate
>> if tests in the makefiles? Then we could also handle more
>> complicated situations like if parmetis, 64 bit indices,
>> datafilespath.
>
> If we continue to specify tests as targets in makefiles, we don't
> necessarily need ugly if tests. One option would be to use
> target-specific variables.
>
> runex123: REQUIRE = parmetis mumps 64-bit-indices
> runex123:
> ${MPIEXEC} -n 2 ./ex123 …
>
I used to hate gnumake but if it supports the syntax above that is much
better than our current approach.
>
> I don't know how to avoid needing to list all the targets once, other
> than to have a script that parses the makefiles and makes that list
> (easy, and can update automatically like the $PETSC_ARCH/conf/files that
> is relatively transparent).
tests: $(shell grep ":" makefile | grep runex | grep -v makefile | sed "s/://g”
)
Unfortunately it is not that simple because for each runexX we need to compile
the example and we only want to compile it once for all its uses and we need to
rm it as soon as it is no longer needed. Perhaps we can list them in the
correct order
ex1: REQUIRE = ccx
runex1: REQUIRE = ccx
stuff
runex1: REQUIRE = ccx ddy
stuff
rmex1:
${RM} -f ex1
then generate at make time with shell the entire list of rules to run starting
at the top
