On Thu, Jul 26, 2012 at 1:30 PM, Matthew Knepley <knepley@gmail.com> wrote:

On Thu, Jul 26, 2012 at 12:21 PM, Jed Brown <jedbrown@mcs.anl.gov> wrote:

Builder does some of this, but I think not all, and I don't think it's as convenient. The differences are partly syntactic. First, to add a test, you have to add lines to a single global file (currently 1500 lines). By creating the dictionary globally, we can't do consistency checks when the test is declared, instead you only do it later once you have lost line number information. You also can't build in the source directory, or anything similar, which makes it hard for a user to split an example out into their own toy project. Since you mess around with stdout, we are losing warning messages (including color) and lose some Emacs M-x compile convenience. (this can be fixed easily enough).

1) I am fine with changing where the options come from, meaning if we want to also check for an import somewhere. Personally, I think
its easier to maintain a central database than a distributed database. I would only suggest a distributed database for scalability, which

we do not need.

2) I take your point about users adding tests (extensibility), which is why I would be fine with checking for an import

3) I have no idea what you mean about consistency checks

Suppose the user misspells a file name or dict key, or they forget a mandatory key. With a dict, all you can do is spit out the entry that you think is corrupt and the user is on their own to figure out where the declaration is in the file. With my model, you immediately get the file and line number where the invalid record was created. With separate files, we can also get more context-sensitive behavior to avoid repeating ourselves so much.

4) You can run builder on source anywhere. This is how I check the crazy things people send us.

Note that my suggestion does not _prevent_ using a global script, but it localizes the declaration and would make it possible to run locally.

On Thu, Jul 26, 2012 at 11:37 AM, Matthew Knepley <knepley@gmail.com> wrote:

./test.py build ex19

$ config/builder2.py buildExample src/snes/examples/tutorials/ex19.c
Namespace(files=['src/snes/examples/tutorials/ex19.c'], func=<function buildExample at 0x1fa56e0>)

Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c']
ERROR IN LINK ****************************** /usr/bin/ld: cannot find -lpetsc collect2: error: ld returned 1 exit status

(maybe it doesn't work --with-single-library=0)

It does not. I don't see a reason to support this. If its does, it is accidental.

It's still a supported option in PETSc. I use it in my default PETSC_ARCH because (a) link is one second faster and (b) it keeps us honest about dependencies.

$ PETSC_ARCH=mpich-singlelib config/builder2.py buildExample src/snes/examples/tutorials/ex19.c

Namespace(files=['src/snes/examples/tutorials/ex19.c'], func=<function buildExample at 0x25dd6e0>)

Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c']

(hmm, where is the executable anyway)

$ ls -ltr | tail -3
lrwxrwxrwx 1 jed users 35 Jul 26 11:57 make.log.bkp -> /home/jed/petsc/mpich/conf/make.log

lrwxrwxrwx 1 jed users 45 Jul 26 11:58 make.log -> /home/jed/petsc/mpich-singlelib/conf/make.log
-rw-r--r-- 1 jed users 5271714 Jul 26 11:58 RDict.log

(oh cool, it overwrote my library build with the make.log from this example)

It shouldn't. It should move make.log to make.log.bkp first. There must be a bug.

So the second time I run it, the original make.log is gone. Not better.

$ cat make.log
Loaded configure to cache: size 298004
Building ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c']
Compiling C files ['/home/jed/petsc/src/snes/examples/tutorials/ex19.c']

Pushing language C
/opt/mpich2/bin/mpicc -c -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/petsc/include -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/usr/elemental-mpich/include -I/usr/include -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= /home/jed/petsc/src/snes/examples/tutorials/ex19.c

sh: /opt/mpich2/bin/mpicc -c -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/petsc/include -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/usr/elemental-mpich/include -I/usr/include -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= /home/jed/petsc/src/snes/examples/tutorials/ex19.c

Executing: /opt/mpich2/bin/mpicc -c -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/petsc/include -I/home/jed/petsc/mpich-singlelib/include -I/home/jed/usr/elemental-mpich/include -I/usr/include -I/opt/mpich2/include -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 -MMD -D__INSDIR__= /home/jed/petsc/src/snes/examples/tutorials/ex19.c

sh:
Popping language C
Moving ex19.o to /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o
Moving ex19.d to /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.d

Linking object ['/home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o'] into /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19
Pushing language C
Pushing language C

Popping language C
Pushing language CUDA
Popping language CUDA
Pushing language Cxx

Popping language Cxx
Pushing language FC
Popping language FC
Pushing language C

Popping language C
sh: /opt/mpich2/bin/mpicc -o /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o -L/home/jed/petsc/mpich-singlelib/lib -lpetsc -Wl,-rpath,/home/jed/petsc/mpich-singlelib/lib -L/home/jed/petsc/mpich-singlelib/lib -ltriangle -lX11 -lchaco -lparmetis -lmetis -Wl,-rpath,/home/jed/usr/elemental-mpich/lib -L/home/jed/usr/elemental-mpich/lib -lelemental -lplcg -lpmrrr -lamspub -lml -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -lmpichcxx -lstdc++ -lpthread -lblacs -lHYPRE -lmpichcxx -lstdc++ -Wl,-rpath,/usr/lib -L/usr/lib -lcholmod -lamd -lcolamd -lcamd -lccolamd -lumfpack -lcholmod -lcamd -lccolamd -lcolamd -lamd -llapack -lblas -lm -L/usr/local/cuda/lib -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -ldl -Wl,-rpath,/opt/mpich2/lib -lmpich -lopa -lmpl -lpthread -lrt -lgcc_s -ldl

Executing: /opt/mpich2/bin/mpicc -o /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19 -fPIC -Wall -Wwrite-strings -Wno-strict-aliasing -Wno-unknown-pragmas -g3 -fno-inline -O0 /home/jed/petsc/mpich-singlelib/lib/ex19-obj/ex19.o -L/home/jed/petsc/mpich-singlelib/lib -lpetsc -Wl,-rpath,/home/jed/petsc/mpich-singlelib/lib -L/home/jed/petsc/mpich-singlelib/lib -ltriangle -lX11 -lchaco -lparmetis -lmetis -Wl,-rpath,/home/jed/usr/elemental-mpich/lib -L/home/jed/usr/elemental-mpich/lib -lelemental -lplcg -lpmrrr -lamspub -lml -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -lmpichcxx -lstdc++ -lpthread -lblacs -lHYPRE -lmpichcxx -lstdc++ -Wl,-rpath,/usr/lib -L/usr/lib -lcholmod -lamd -lcolamd -lcamd -lccolamd -lumfpack -lcholmod -lcamd -lccolamd -lcolamd -lamd -llapack -lblas -lm -L/usr/local/cuda/lib -Wl,-rpath,/opt/mpich2/lib -L/opt/mpich2/lib -Wl,-rpath,/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1 -ldl -Wl,-rpath,/opt/mpich2/lib -lmpich -lopa -lmpl -lpthread -lrt -lgcc_s -ldl

sh:
Popping language C

(the above output loses warnings)

Bug.

$ mpich-singlelib/lib/ex19-obj/ex19 -happy-running

./test.py check ex19_fas

$ PETSC_ARCH=mpich-singlelib config/builder2.py check --testnum 5 src/snes/examples/tutorials/ex19.c
Namespace(args=[], files=['src/snes/examples/tutorials/ex19.c'], func=<function check at 0xfe17d0>, retain=False, testnum=5)

All tests pass

(edit file, insert syntax error, re-run)

[same output as above]

./test.py check ex19_\* # run all the ex19 tests

./test.py check -n 16 --if '(X || Fortran) && !Complex'

How?

Internally it knows all these predicates like num processes, Fortran and complex.

It knows Fortran only in that the source file is Fortran. How does it know whether an example supports complex or whether a given run uses SuperLU, etc?

There is no command line syntax for it. I did
not think there was for make either.

It's manual through TESTEXAMPLES_SUPERLU, etc.

You can do that from the run parameters at the op of builder.py.

I don't think so. I think you have to add another dict key to your example declarations.