Open drew-parsons opened 2 years ago
Incidently the test build succeeds and tests pass if I edit the .obj to .o in test/Makefile.
Hi @drew-parsons The reason we kept some .obj
was those drivers use GPU boxloops so had to be compiled as C++. All the drivers actually were supposed to be compiled as C, since we want hypre to be linked as a C library even in the GPU build. They will eventually go to .c
at some point.
I don't know why you saw the No rule to make target
issue. It did not happen to me, see
li50@lassen555:~/workspace/hypre/master/src/test$ make struct
/usr/tce/packages/cuda/cuda-10.1.243/bin/nvcc -ccbin=mpixlC -gencode arch=compute_70,code=sm_70 -O2 -lineinfo -expt-extended-lambda -std=c++11 --x cu -Xcompiler "-O2 " -DHAVE_CONFIG_H -I. -I/g/g92/li50/workspace/hypre/master/src/hypre/include -I/usr/tce/packages/cuda/cuda-10.1.243/include -DHYPRE_TIMING -DHYPRE_FORTRAN -c struct.c -o struct.obj
Building struct ...
mpixlC -o struct struct.obj -L/g/g92/li50/workspace/hypre/master/src/hypre/lib -lHYPRE -Wl,-rpath,/g/g92/li50/workspace/hypre/master/src/hypre/lib -lm -L/usr/tce/packages/cuda/cuda-10.1.243/lib64 -lcudart -lcusparse -lcurand
li50@lassen555:~/workspace/hypre/master/src/test$ make sstruct
mpixlc -O2 -DHAVE_CONFIG_H -I. -I/g/g92/li50/workspace/hypre/master/src/hypre/include -I/usr/tce/packages/cuda/cuda-10.1.243/include -DHYPRE_TIMING -DHYPRE_FORTRAN -c sstruct.c
Building sstruct ...
mpixlC -o sstruct sstruct.o -L/g/g92/li50/workspace/hypre/master/src/hypre/lib -lHYPRE -Wl,-rpath,/g/g92/li50/workspace/hypre/master/src/hypre/lib -lm -L/usr/tce/packages/cuda/cuda-10.1.243/lib64 -lcudart -lcusparse -lcurand
Maybe I missed something? Thanks!
Hi @liruipeng , test logs on Debian CI are now available to see more of what the tests are doing, e.g. https://ci.debian.net/packages/h/hypre/unstable/amd64/ with a 2.23.0 test log at https://ci.debian.net/data/autopkgtest/unstable/amd64/h/hypre/19202783/log.gz
cuda is not being used here, so CUCC is not defined.
I think my .obj build failure is happening because the Debian tests have commented out the line
include ../config/Makefile.config
in src/test/Makefile
The reason this is done is because these are CI tests intended to verify that the existing packages continue to run fine. That is, these are not build-time tests (at build time the tests are passing fine, see https://buildd.debian.org/status/package.php?p=hypre&suite=experimental)
Hence config/Makefile.config does not exist, which is why the include line was commented out in test/Makefile (the tests are being run directly from src/test).
How are the tests intended to be launched for building against installed HYPRE libraries, without building the libraries (or running src/configure) anew? There's the AUTOTEST dir, but that doesn't seem to help.
I'm able to proceed with installation testing by replacing
include ../config/Makefile.config
in src/test/Makefile with the missing declarations for handling .obj that would otherwise be in Makefile.config:
.SUFFIXES:
.SUFFIXES: .o .obj .f .c .C .cxx .cc
ifeq ($(CUCC), )
.c.obj:
$(CC) $(CFLAGS) -c $< -o $@
else
.c.obj:
$(CUCC) $(CUFLAGS) -c $< -o $@
endif
So the issue here is not compiling struct.obj (that was due to the original hack I made on src/test/Makefile), but rather providing a way of testing installed hypre libraries.
It would be helpful for distributions such as debian to be able to run CI testing on the installed libraries (rather than freshly built libraries).
Is there a way that src/test/Makefile can be adapted to facilitate both kinds of testing? Perhaps a environment (or Makefile) variable that can be set to distinguish between build-time tests using config/Makefile.config, and installation tests of existing installed libraries ?
I'm changing the title of the Issue to reflect this question.
PR #461 (commit 298a5bf8d0, hypre 2.23.0) changed the object suffix for test programs in test/Makefile.
Previously
.${OBJ_SUFFIX}
was used, with OBJ_SUFFIX set to o or obj depending on whether CUCC was defined or not.PR #461 changed the object suffices for each target to a fixed value, but it seems to have been done inconsistently. Most targets were changed to .o, but a couple (struct.obj, struct_migrate.obj, zboxloop.obj) were changed to .obj.
This means when
make
is run in the test dir, meaning to make all test targets, the build fails once the struct target is reach:This is on Linux, debian unstable, CC=gcc, gcc 11.2.0.
I can't see any key difference in the test source code, e.g. comparing sstruct.c to struct.c, that the former should need to compile to sstruct.o while the latter needs struct.obj. The sstruct compilation succeeds (with sstruct.o).
As far as I can tell all targets should be compiling to .o not .obj.
There was discussion on this point in PR#461, but that discussion concluded with "We should talk about it at some point.". Time to talk.