[petsc-dev] getting rid of TESTEXAMPLES_XXX_XXX stuff

Barry Smith bsmith at mcs.anl.gov
Tue Dec 3 06:03:25 CST 2013


On Dec 2, 2013, at 10:33 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

> Barry Smith <bsmith at mcs.anl.gov> writes:
>> 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
> 
> For normal examples, we don't need special targets because this will
> work for all of them.
> 
> ex%: ex%.o | chkopts
> 	-${CLINKER} -o $@ $< ${PETSC_TS_LIB}

   In tests we use the funky .PETSc rule to compile the examples without displaying the compile/link output (on success since clutters the output enormously) but does display the output on failed compile/link. How can we get the same effect with this rule?  I can’t live with that output.

   Barry

> 
> With pattern rules like this, the intermediate files ex*.o are
> automatically deleted after compilation, so we would not need the hack
> of deleting it explicitly (which has the undesirable side-effect of
> returning success even when linking fails).  When switching PETSC_ARCH,
> users can add -B to ensure recompilation.
> 
> Note that it is natural to state the dependency
> 
> runex123 : ex123
> 
> so that the examples are automatically built.  If we also use
> 
> .INTERMEDIATE: ex123
> 
> then "make runex123 runex123_2" would build ex123 (once), run the two
> examples (in parallel if you used -j), and delete the executable ex123.
> 
> 
> But for testing, I would much prefer to compile one executable per
> package.  I have code for this, and it builds all the examples in PETSc
> in 30 seconds, but I stalled on the test harness.  I can push the proof
> of concept in a branch.  Simply compiling all the examples fast in a
> single target would be useful to root out issues with API changes.




More information about the petsc-dev mailing list