dgasmith / gau2grid Goto Github PK
View Code? Open in Web Editor NEWFast computation of a gaussian and its derivative on a grid.
Home Page: https://gau2grid.readthedocs.io/en/latest/
License: BSD 3-Clause "New" or "Revised" License
Fast computation of a gaussian and its derivative on a grid.
Home Page: https://gau2grid.readthedocs.io/en/latest/
License: BSD 3-Clause "New" or "Revised" License
As @loriab pointed out the molden
order is not hooked up to build.
The following lines (at least) need to be fixed:
https://github.com/dgasmith/gau2grid/blob/master/CMakeLists.txt#L17, https://github.com/dgasmith/gau2grid/blob/master/CMakeLists.txt#L33, https://github.com/dgasmith/gau2grid/blob/master/cmake/gau2gridConfig.cmake.in#L50-L54, https://github.com/dgasmith/gau2grid/blob/master/cmake/gau2gridConfig.cmake.in#L17-L18
This is reproducible.
cmake -H. -Bbuild -DCMAKE_C_COMPILER=gcc-8 -DCMAKE_CXX_COMPILER=g++-8 -DCMAKE_Fortran_COMPILER=gfortran-8
Homebrew installed gcc-8
Components of NWChemEx cannot compile properly with clang, hence we are using gcc on a Mac right now. Not clear where it goes wrong. Most likely the path to the include file is not found?
Bert
Originally posted by @wadejong in #42 (comment)
I need to get this packaged in Fedora so that I can finally update psi4 to the 1.2 series.
However, gau2grid doesn't have an soname, which should be added.
https://fedoraproject.org/wiki/Packaging:Guidelines#Downstream_.so_name_versioning
Make mpmath an optional dependency only if one wishes to extend the maximum angular momentum. Accomplish this by pre-compiling and serializing up to AM=16 so that this maximum is not often hit.
Would it be possible to tag 757e615, so in psi4/psi4#1124 I could refer to a tag rather than a hash.
I've been running various DFT calculations with PSI4 inside Intel's VTune and gg_fast_transpose
popped up a top hotspot As as test I exchanged it to gg_naive_transpose
and saw a significant speed up (50% for a C60 test) for that function.
It's only 4-5% of the total CPU time for single-points, so no real bottleneck to worry about, but wondering why the blocked-transpose might be so much slower.
-- Found Python 2.7: /usr/local/bin/python2.7 (found version 2.7.15)
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'commonpath'
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'commonpath'
CMake Error at CMakeLists.txt:163 (install):
install DIRECTORY given no DESTINATION!
-- Configuring incomplete, errors occurred!
See also "/usr/ports/math/py-gau2grid/work-py27/gau2grid-1.3.1/build/temp.freebsd-11.2-STABLE-amd64-2.7/CMakeFiles/CMakeOutput.log".
See also "/usr/ports/math/py-gau2grid/work-py27/gau2grid-1.3.1/build/temp.freebsd-11.2-STABLE-amd64-2.7/CMakeFiles/CMakeError.log".
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "setup.py", line 147, in <module>
zip_safe=False,
File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line 143, in setup
return distutils.core.setup(**attrs)
File "/usr/local/lib/python2.7/distutils/core.py", line 151, in setup
dist.run_commands()
File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
self.run_command(cmd)
File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "/usr/local/lib/python2.7/distutils/command/build.py", line 127, in run
self.run_command(cmd_name)
File "/usr/local/lib/python2.7/distutils/cmd.py", line 326, in run_command
self.distribution.run_command(command)
File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
cmd_obj.run()
File "setup.py", line 33, in run
self.build_extension(ext)
File "setup.py", line 56, in build_extension
subprocess.check_call(['cmake', ext.sourcedir] + internal_cmake_args, cwd=self.build_temp, env=env)
File "/usr/local/lib/python2.7/subprocess.py", line 190, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '/usr/ports/math/py-gau2grid/work-py27/gau2grid-1.3.1', '-DPYTHON_EXECUTABLE=/usr/local/bin/python2.7', '-DSPHERICAL_ORDER=gaussian', '-DINSTALL_PYMOD=ON', '-DENABLE_XHOST=ON', '-DBUILD_FPIC=ON', '-DBUILD_SHARED_LIBS=ON', '-DMAX_AM=6', '-DENABLE_GENERIC=OFF', '-DCARTESIAN_ORDER=row', '-DCMAKE_BUILD_TYPE=Release', '-DNATIVE_PYTHON_INSTALL=ON', '-DCMAKE_BUILD_TYPE=Release']' returned non-zero exit status 1
*** Error code 1
Worked fine in version 1.3.0
FreeBSD 11.2 amd64
gau2grid has been approved in Fedora, but the builds fail on every other architecture than x86_64.
https://koji.fedoraproject.org/koji/taskinfo?taskID=29866555
It appears there are at least two separate issues in the code.
First, on i686 and armv7hl I get
[ 14%] Generating gau2grid.h, gau2grid_phi.c, gau2grid_deriv1.c, gau2grid_deriv2.c, gau2grid_spherical.c, gau2grid_helper.c
/usr/bin/python3.7 -c "import sys; sys.path.append('/builddir/build/BUILD/gau2grid-1.2.0'); import gau2grid as gg; gg.c_gen.generate_c_gau2grid(8, path='/builddir/build/BUILD/gau2grid-1.2.0/objdir', cartesian_order='row', spherical_order='gaussian')"
Traceback (most recent call last):
File "/usr/lib/python3.7/site-packages/numpy/lib/format.py", line 527, in _read_array_header
dtype = numpy.dtype(d['descr'])
TypeError: data type "<f16" not understood
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/builddir/build/BUILD/gau2grid-1.2.0/gau2grid/__init__.py", line 5, in <module>
from . import RSH
File "/builddir/build/BUILD/gau2grid-1.2.0/gau2grid/RSH.py", line 43, in <module>
_load_saved_rsh_coefs()
File "/builddir/build/BUILD/gau2grid-1.2.0/gau2grid/RSH.py", line 29, in _load_saved_rsh_coefs
coefs = rsh_data[key_name + "coeffs"]
File "/usr/lib/python3.7/site-packages/numpy/lib/npyio.py", line 251, in __getitem__
pickle_kwargs=self.pickle_kwargs)
File "/usr/lib/python3.7/site-packages/numpy/lib/format.py", line 642, in read_array
shape, fortran_order, dtype = _read_array_header(fp, version)
File "/usr/lib/python3.7/site-packages/numpy/lib/format.py", line 530, in _read_array_header
raise ValueError(msg % (d['descr'],))
ValueError: descr is not a valid dtype descriptor: '<f16'
Second, on ppc64le, aarch64 and s390x I get
[ 28%] Building C object CMakeFiles/gg.dir/gau2grid_phi.c.o
/usr/bin/cc -Dgg_EXPORTS -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mcpu=power8 -mtune=power8 -fasynchronous-unwind-tables -fstack-clash-protection -DNDEBUG -fPIC -std=c99 -o CMakeFiles/gg.dir/gau2grid_phi.c.o -c /builddir/build/BUILD/gau2grid-1.2.0/objdir/gau2grid_phi.c
/builddir/build/BUILD/gau2grid-1.2.0/objdir/gau2grid_phi.c:13:10: fatal error: mm_malloc.h: No such file or directory
#include <mm_malloc.h>
^~~~~~~~~~~~~
compilation terminated.
It would be useful to be able to compile multiple versions of gau2grid with different ordering paths. This would require prefixes on all functions and headers.
Note: this is not a bug, just a suggestion for an improvement.
Would it be possible to generate a more generic C interface viz the specification style for Cartesian points into the drivers? Currently, the specification dictates that the Cartesian points be specified as 3 unit-stride arrays of length "N". Specifically what I'm looking for is one of the following
A specification which allows a single unit stride array of length 3*N which contains the cartesian points contiguously
A more flexible specification which allows the user to specify the stride of the X,Y,Z arrays, e.g. the X array could be length N with stride 3.
Currently, the only option for spherical Gaussians is to be returned in the Gaussian ordering
[0, -1, +1, -2, +2, ..., -L, +L]
CCA dictates the order
[-L, -L+1, -L+2, ..., 0, L+1, L+2, ... L]
Both orderings are common place in KS codes, thus this would be a useful option to set at configuration
Tagged version doesn't match CMake project version:
Line 4 in 757e615
As a result, Psi4 configuration fails: https://travis-ci.org/psi4/psi4/jobs/412702471
CMake Error at cmake_install.cmake:36 (file):
file INSTALL cannot make directory
"/usr/local/lib/python3.6/site-packages/gau2grid": Permission denied
1.3.0 worked fine.
FreeBSD 11.2 amd64
Right now, for L>0 basis functions, the code only allows a single coefficient. I would like to individually specify coefficients for each component of a L>0 function. For instance, I would like to specify a coefficient c_x for p_x, but a different c_y for p_y and so on. I hope this makes sense.
I have a workaround right now, but it does not work with the collocation_basis
function, which would be much cleaner and faster. I'm hoping that adding this shouldn't be too difficult.
When trying to build gau2grid with gcc 8.2.0
on macOS, I get a
lot of the following warnings
/tmp/gau2grid/build/gau2grid_deriv2.c: In function 'gg_collocation_L8_deriv2':
/tmp/gau2grid/build/gau2grid_pragma.h:35:62: warning: incompatible implicit declaration of built-in function 'aligned_alloc'
#define ALIGNED_MALLOC(alignment, size) aligned_alloc(alignment, size)
^~~~~~~~~~~~~
/tmp/gau2grid/build/gau2grid_deriv2.c:5637:51: note: in expansion of macro 'ALIGNED_MALLOC'
double* PRAGMA_RESTRICT cache_data = (double*)ALIGNED_MALLOC(64, 256 * sizeof(double));
^~~~~~~~~~~~~~
/tmp/gau2grid/build/gau2grid_pragma.h:35:62: note: include '<stdlib.h>' or provide a declaration of 'aligned_alloc'
#define ALIGNED_MALLOC(alignment, size) aligned_alloc(alignment, size)
finally resulting in a linker error:
Undefined symbols for architecture x86_64:
"_aligned_alloc", referenced from:
_gg_collocation_L0 in gau2grid_phi.c.o
_gg_collocation_L1 in gau2grid_phi.c.o
_gg_collocation_L2 in gau2grid_phi.c.o
_gg_collocation_L3 in gau2grid_phi.c.o
_gg_collocation_L4 in gau2grid_phi.c.o
_gg_collocation_L5 in gau2grid_phi.c.o
_gg_collocation_L6 in gau2grid_phi.c.o
...
ld: symbol(s) not found for architecture x86_64
I tried to include <stdlib.h>
in the respective file, but it did not seem to work.
Any ideas on this issue?
[...Extending an offline discussion...]
Currently, the build requires numpy to generate the C interface. Since there''s not currently any arch deduction (mu-arch, cache sizes, etc) in the CMake build and all optimizations are handled by #pragma simd
etc, it should be possible to distribute pregenerated C source source code to avoid the generation step for each release. I'm kind of envisioning something that resembles the release structure generated by Libint where the "compiler" (code generation) and exported libs are separate
I got a bug report from the automatic testing infrastructure about psi4 and gau2grid, see
https://ci.debian.net/data/autopkgtest/testing/amd64/p/psi4/3146850/log.gz
It seems psi4 crashed in libgg if it was originally built against 1.3.1 but is now dynamically linked to 2.0. This is possible as the SONAME
did not change and might hint at the fact that it should have been changed?
Here is the backtrace:
Nuclear repulsion energy..........................................PASSED
SCF energy........................................................PASSED
SCF DIPOLE X......................................................PASSED
SCF DIPOLE Y......................................................PASSED
SCF DIPOLE Z......................................................PASSED
SCF QUADRUPOLE XX.................................................PASSED
SCF QUADRUPOLE YY.................................................PASSED
SCF QUADRUPOLE ZZ.................................................PASSED
SCF QUADRUPOLE XY.................................................PASSED
SCF QUADRUPOLE XZ.................................................PASSED
SCF QUADRUPOLE YZ.................................................PASSED
Program received signal SIGSEGV, Segmentation fault.
gg_collocation_L0_deriv1 (npoints=npoints@entry=63, xyz=0x1c15630, xyz_stride=29971088, nprim=30494448, coeffs=0x1, exponents=0x1279180, center=0xee0ec0, order=14698288, phi_out=0x0, phi_x_out=0x1b171a0,
phi_y_out=0x1b62200, phi_z_out=0x1b6ea10) at ./obj-x86_64-linux-gnu/gau2grid_deriv1.c:80
80 ./obj-x86_64-linux-gnu/gau2grid_deriv1.c: No such file or directory.
(gdb) bt
#0 gg_collocation_L0_deriv1 (npoints=npoints@entry=63, xyz=0x1c15630, xyz_stride=29971088, nprim=30494448, coeffs=0x1, exponents=0x1279180, center=0xee0ec0, order=14698288, phi_out=0x0, phi_x_out=0x1b171a0,
phi_y_out=0x1b62200, phi_z_out=0x1b6ea10) at ./obj-x86_64-linux-gnu/gau2grid_deriv1.c:80
#1 0x00007ffff59447c0 in gg_collocation_deriv1 (L=L@entry=0, npoints=npoints@entry=63, xyz=xyz@entry=0x1c15630, xyz_stride=xyz_stride@entry=29971088, nprim=nprim@entry=30494448, coeffs=<optimized out>,
exponents=<optimized out>, center=<optimized out>, order=<optimized out>, phi_out=<optimized out>, phi_x_out=<optimized out>, phi_y_out=<optimized out>, phi_z_out=0x1b6ea10)
at ./obj-x86_64-linux-gnu/gau2grid_helper.c:86
#2 0x00007ffff6f2ab7b in psi::BasisFunctions::compute_functions (this=0x1a76f10, block=...) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libfock/points.cc:705
#3 0x00007ffff6f2cf90 in psi::UKSFunctions::compute_points (this=this@entry=0x1a76f10, block=std::shared_ptr<class psi::BlockOPoints> (use count 4, weak count 0) = {...})
at /usr/include/c++/8/ext/atomicity.h:96
#4 0x00007ffff6f6cd0d in psi::UV::compute_V (this=0x12dd250, ret=std::vector of length 2, capacity 2 = {...}) at /usr/include/c++/8/bits/shared_ptr.h:129
#5 0x00007ffff6e882ae in psi::scf::UHF::form_V (this=0x1463560) at /usr/include/c++/8/ext/atomicity.h:98
#6 0x00007ffff6e8d657 in psi::scf::UHF::form_G (this=0x1463560) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libscf_solver/uhf.cc:181
#7 0x00007ffff6e5b016 in psi::scf::HF::iterations (this=0x1463560) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libscf_solver/hf.cc:1645
#8 0x00007ffff6e50a09 in psi::scf::HF::compute_energy (this=0x1463560) at /build/psi4-3cv7JI/psi4-1.2.1/psi4/src/psi4/libscf_solver/hf.cc:490
#9 0x00007ffff635a75e in pybind11::cpp_function::cpp_function<double, psi::Wavefunction, , pybind11::name, pybind11::is_method, pybind11::sibling, char [41]>(double (psi::Wavefunction::*)(), pybind11::name const&, pybind11::is_method const&, pybind11::sibling const&, char const (&) [41])::{lambda(psi::Wavefunction*)#1}::operator()(psi::Wavefunction*) const (this=<optimized out>, this=<optimized out>,
c=<optimized out>) at /usr/include/pybind11/pybind11.h:72
The last lines in output.dat
are:
==> DiskJK: Disk-Based J/K Matrices <==
J tasked: Yes
K tasked: Yes
wK tasked: No
Memory (MB): 375
Schwarz Cutoff: 1E-12
OpenMP threads: 1
Minimum eigenvalue in the overlap matrix is 2.6982852745E-02.
Using Symmetric Orthogonalization.
SCF Guess: Generalized Wolfsberg-Helmholtz.
==> Iterations <==
Total Energy Delta E RMS |[F,P]|
This is with gau2grid 2.0.1, I just saw that 2.0.3 got released and I am going to upload it to Debian right now, but I assume chances are slim that it would be fixed by that?
Using python setup.py install
(miniconda python) the data
directory is missing and needs to be copied manually to the correct location.
Ideally, gau2grid
could be included in a downstream CMake project as
FetchContent_Declare( gau2grid GIT_REPOSITORY https://github.com/dgasmith/gau2grid.git )
FetchContent_MakeAvailable( gau2grid )
target_link_libraries( my_target PUBLIC gg )
This populates directories ${CMAKE_BINARY_DIR}/_deps/gau2grid-src
, etc. The generator on line 58 assumes that CMAKE_SOURCE_DIR
and PROJECT_SOURCE_DIR
are the same, which is not the case through FetchContent. Making this generator point explicitly to PROJECT_SOURCE_DIR
fixes the problem.
A (albeit hacky) workaround of this is the following
FetchContent_Declare(
gau2grid
GIT_REPOSITORY https://github.com/dgasmith/gau2grid.git
)
FetchContent_GetProperties( gau2grid )
if( NOT gau2grid_POPULATED )
FetchContent_Populate( gau2grid )
file( READ ${gau2grid_SOURCE_DIR}/CMakeLists.txt GAU2GRID_CMAKE_LISTS )
string( REPLACE "CMAKE_SOURCE_DIR" "PROJECT_SOURCE_DIR" GAU2GRID_CORRECT "${GAU2GRID_CMAKE_LISTS}" )
file( WRITE ${gau2grid_SOURCE_DIR}/CMakeLists.txt "${GAU2GRID_CORRECT}" )
add_subdirectory( ${gau2grid_SOURCE_DIR} ${gau2grid_BINARY_DIR} )
endif()
The --record plist
python feature fails to add this file to the plist.
===> Checking for items in STAGEDIR missing from pkg-plist
Error: Orphaned: %%PYTHON_SITELIBDIR%%/gau2grid/libgg.so.1
===> Checking for items in pkg-plist which are not in STAGEDIR
===> Error: Plist issues found.
*** Error code 1
Version 1.3.0
fails:
[ 12%] Generating gau2grid.h, gau2grid_orbital.c, gau2grid_phi.c, gau2grid_deriv1.c, gau2grid_deriv2.c, gau2grid_spherical.c, gau2grid_helper.c
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/gau2grid/c_generator.py", line 151, in generate_c_gau2grid
sig = RSH.transformation_c_generator(gg_spherical, L, cartesian_order, spherical_order, align=ALIGN_SIZE)
File "/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/gau2grid/RSH.py", line 268, in transformation_c_generator
RSH_coefs = cart_to_RSH_coeffs(L, order=spherical_order)
File "/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/gau2grid/RSH.py", line 177, in cart_to_RSH_coeffs
data = _saved_rsh_coefs[L]
KeyError: 0
gmake[3]: *** [CMakeFiles/gg.dir/build.make:62: gau2grid.h] Error 1
gmake[3]: Leaving directory '/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/build/temp.freebsd-11.2-STABLE-amd64-3.6'
gmake[2]: *** [CMakeFiles/Makefile2:72: CMakeFiles/gg.dir/all] Error 2
gmake[2]: Leaving directory '/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/build/temp.freebsd-11.2-STABLE-amd64-3.6'
gmake[1]: *** [Makefile:130: all] Error 2
gmake[1]: Leaving directory '/usr/ports/math/py-gau2grid/work-py36/gau2grid-1.3.0/build/temp.freebsd-11.2-STABLE-amd64-3.6'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "setup.py", line 143, in <module>
zip_safe=False, )
File "/usr/local/lib/python3.6/site-packages/setuptools/__init__.py", line 143, in setup
return distutils.core.setup(**attrs)
File "/usr/local/lib/python3.6/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/local/lib/python3.6/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
File "/usr/local/lib/python3.6/distutils/dist.py", line 974, in run_command
cmd_obj.run()
File "/usr/local/lib/python3.6/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
File "/usr/local/lib/python3.6/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/local/lib/python3.6/distutils/dist.py", line 974, in run_command
cmd_obj.run()
File "setup.py", line 33, in run
self.build_extension(ext)
File "setup.py", line 60, in build_extension
subprocess.check_call(['cmake', '--build', '.'] + build_args, cwd=self.build_temp)
File "/usr/local/lib/python3.6/subprocess.py", line 291, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--config', 'Release', '--', '-j2']' returned non-zero exit status 2.
The underlying cmake
command fails:
$ cmake --build . --config Release -- -j2
Error: could not load cache
$ cmake .
A simpler cmake
command also fails:
$ cmake .
...
...
-- Setting (unspecified) option INSTALL_PYMOD: OFF
CMake Error at cmake/autocmake_safeguards.cmake:16 (message):
In-source builds not allowed. Please run CMake from top directory and
specify a build directory (e.g., cmake -H. -Bbuild).
Call Stack (most recent call first):
CMakeLists.txt:47 (include)
-- Configuring incomplete, errors occurred!
I would like to integrate this into Avogadro, and make use of it in a desktop application. In addition, this is wrapped, and used on a server to deliver to web clients using a RESTful API. We effectively load up Gaussian basis sets, and an MO coefficient matrix.
I currently map each basis function to an atom, with a position in space, and then parallelise the code on the grid, effectively giving a smaller grid to each core, writing directly into it from all threads but ensuring only one thread will ever attempt to write to any given scalar. The code figures out which index to write to, its Cartesian position in space, and then iterates over all basis functions for the supplied molecular orbital.
I am open to reorganizing the code, but would like to maintain the high level interface. Load quantum output, then calculate the MO cube, which is then further processed before being visualized. It would be helpful to understand how I would map our basis sets, MO matrix, and atom positions in. Also what the most efficient method of passing in a subset of the cube, and whether we would need multiple copies of the data per thread, or could maintain the single copy that is only read across all threads.
Just updating the Debian packaging to 1.3.1 results in a build/install failure:
[100%] Built target gg
make[3]: Leaving directory '/<<PKGBUILDDIR>>/build/temp.linux-amd64-3.7'
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/lib/python3/dist-packages/gau2grid
CMake Error at cmake_install.cmake:41 (file):
file INSTALL cannot make directory
"/usr/lib/python3/dist-packages/gau2grid": Permission denied
make[2]: *** [Makefile:118: install] Error 1
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build/temp.linux-amd64-3.7'
Traceback (most recent call last):
File "setup.py", line 147, in <module>
zip_safe=False,
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 143, in setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3.7/distutils/core.py", line 148, in setup
dist.run_commands()
File "/usr/lib/python3.7/distutils/dist.py", line 966, in run_commands
self.run_command(cmd)
File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "/usr/lib/python3.7/distutils/command/build.py", line 135, in run
self.run_command(cmd_name)
File "/usr/lib/python3.7/distutils/cmd.py", line 313, in run_command
self.distribution.run_command(command)
File "/usr/lib/python3.7/distutils/dist.py", line 985, in run_command
cmd_obj.run()
File "setup.py", line 33, in run
self.build_extension(ext)
File "setup.py", line 58, in build_extension
subprocess.check_call(['cmake', '--build', '.', '--target', 'install'], cwd=self.build_temp)
File "/usr/lib/python3.7/subprocess.py", line 347, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['cmake', '--build', '.', '--target', 'install']' returned non-zero exit status 2.
I think the root of the problem is that setup.py
now runs install in the build_extension
stanza, via 6f720c5:
subprocess.check_call(['cmake', '--build', '.', '--target', 'install'], cwd=self.build_temp)
During build, $DESTDIR
is not setup by packaging infrastructure so it tries to install into the root filesystem, not the staging one.
Not sure how install should work otherwise (I've never seen in handled specifically in setup.py
), why was that line added in 1.3.1 and what's the purpose? If I remove it, gau2grid builds/installs just fine for me; this is what gets run (and which is mostly in line with README.md
):
/usr/bin/python3 setup.py install --root `pwd`/debian/tmp
/cc @loriab
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.