On Dec 2, 2013, at 10:10 PM, Barry Smith <[email protected]> wrote:
> > 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 Ok, I don’t understand this syntax at all, there is no mention of REQUIRE used in this way in the gnumake manual. How are you proposing to use this variable? >> 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 > >
