Closed loriab closed 3 years ago
(from other thread) There's not a naming standard that I know of, but find_package(Libint2)
, find_package(Libint3)
, and find_package(Libint)
should do nicely for 2, 3, 1, respectively. If I had been more thoughtful, I'd have written the last as Libint1
, but there's no point in switching now.
What does __COMPILING_LIBINT2
indicate? Or, is there any phase (building generator, building library, building export, building exported library) in which it should not be set?
Do I gather correctly that the Cartesian shell ordering is used in building the generator, while the spherical shell ordering is not, thus the generated code has fixed Cart ordering but flexible (until library configuration time) spherical ordering? When does shell_set=standard/orca get fixed?
As an update,
conda install libint2 -c psi4/label/dev
build_libint
executable, build_libint
and build step is make the tarball, build_libint
and build the library directly.configure
by CMakeLists.txt
is in pretty good shape at present. Though I've been focussing on the c++11 interface, not the earlier (and perhaps more widely used) one.While Psi4 is still in the testing and tuning phases of Libint2 integration (https://github.com/psi4/psi4/pull/1721), and this PR isn't complete (Windows not fully working), most major features are in, and it's ready for consideration. @evaleev, please let me know if you have any questions, especially about the strategy.
configure
translated to CMake.pc
file for the libtool folks. Also has Libint2Config.cmake
that supports components like sss
to indicate all standard orderings and g4
to indicate that ERIs of at least deriv=1 and am=4 have been built so that packages can determine if a Libint is right for them at detection time.int2
as opposed to cxx
target)#undef
in the config.h.cmake.in file. I'm adding them as I figure out what they doThis is rebased and passing.
Update from above. @evaleev, what's your hoped/needed timeframe for this PR? Things that must be done, imo, is eigen/mpfr dep detection. Thing that ought to be done is some manner of CI testing the pure cmake build. Otherwise, this is working as well as Psi4 needs it to.
configure
translated to CMake.pc
file for the libtool folks. Also has Libint2Config.cmake
that supports components like sss
to indicate all standard orderings and g4
to indicate that ERIs of at least deriv=1 and am=4 have been built so that packages can determine if a Libint is right for them at detection time.int2
as opposed to cxx
target)#undef
in the config.h.cmake.in file. I'm adding them as I figure out what they doLibint2Config.cmake
.@loriab I am starting on this now. Looks like the biggest missing piece is docs update ... what are you thinking re: Eigen + MPFR? FetchContent, if missing?
Great, thank you!
On docs, I was supposing the in-file descriptions https://github.com/evaleev/libint/pull/148/files#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR16-R195 would do and be most likely to be kept up-to-date. Were you thinking about an alternate to https://github.com/evaleev/libint/wiki#compiling-libint-compiler? For the per-qc-program options section, some psi4 guidance is here (https://github.com/psi4/psi4/blob/master/external/upstream/libint2/CMakeLists.txt). And an example of the production build and absolute smallest possible build (for static analysis) are:
cmake -H. -Bbuild50 \
-GNinja \
-DCMAKE_INSTALL_PREFIX=/home/psilocaluser/gits/libint2/install-50 \
-DCMAKE_CXX_COMPILER=$CXX \
-DCMAKE_C_COMPILER=$CC \
-DEigen3_DIR=$CONDA_PREFIX/share/eigen3/cmake/ \
-DMPFR_ROOT=$CONDA_PREFIX \
-DBOOST_ROOT=$CONDA_PREFIX \
-DLIBINT2_SHGAUSS_ORDERING=gaussian \
-DERI3_PURE_SH=OFF \
-DERI2_PURE_SH=OFF \
-DBUILD_SHARED=ON \
-DBUILD_STATIC=OFF \
-DBUILD_TESTING=ON \
-DENABLE_ERI=2 \
-DENABLE_ERI3=2 \
-DENABLE_ERI2=2 \
-DENABLE_ONEBODY=1 \
-DDISABLE_ONEBODY_PROPERTY_DERIVS=ON \
-DMULTIPOLE_MAX_ORDER=4 \
-DWITH_ERI_MAX_AM="7;7;4" \
-DWITH_ERI3_MAX_AM="7;7;5" \
-DWITH_ERI2_MAX_AM="7;7;5" \
-DWITH_MAX_AM="7;7;5"
-DENABLE_ERI=0 \
-DENABLE_ONEBODY=-1 \
-DDISABLE_ONEBODY_PROPERTY_DERIVS=ON \
-DMULTIPOLE_MAX_ORDER=0 \
-DWITH_ERI_MAX_AM="1" \
-DWITH_MAX_AM="1"
Were there some docs sections you'd like me to draft?
I haven't usually built or offered to fetch-and-build software that's non-QC (pb11 excepted). So I was going to expect mpfr and eigen to be present and fail if not. With eigen being header-only, I can see treating it like boost and unpacking and installing and exporting a tarball. gmp/mpfr is trickiest, with an actual library. I've written a fancier FindMPFR.cmake, but its integration is WIP since I haven't gotten it to link libint2 with a system mpfr. What do you think of handling eigen like boost?
@loriab
dox: at the minimum we need to update INSTALL
(while at it might as well rename to INSTALL.md
). End users do not seem to be OK with reading source, not sure why ;) Long-term I'd like to convert the wiki into markdown embedded into Doxygen, along the lines of what I did for TiledArray: https://valeevgroup.github.io/tiledarray/dox-master/
building exported lib: how about just FetchContent
ing the tarball as subproject? From our multiyear experience with ExternalProject_add
it is tedious to maintain all cmake args to the external project's cmake (there is no transparent way to to pass all of them) and handle all corner cases. E.g. currently configuring library
is broken when I try on arm64/macOS without any args because CMAKE_C_COMPILER
is not specified:
-- The C compiler identification is unknown
CMake Error at tests/CMakeLists.txt:33 (enable_language):
No CMAKE_C_COMPILER could be found.
Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
probably want to eliminate the autotools harness.
re: dependencies ... in my experience need to use systemwide or user-provided packages, but fetchcontent if missing, for all dependencies. Libint is not bad itself, only has < 5 deps at the moment, but some parts of the code could use e.g. better transposes (e.g. if MKL if available) ... I would avoid header-only route as its difficult to maintain ... header-only = macros instead of proper build system (basically, consumer ends up duplicating cmake code that belongs in the "header-only" package)
some options seem to duplicate standard CMake vars ... ? should we use CMAKE_POSITION_INDEPENDENT_CODE
(https://cmake.org/cmake/help/latest/variable/CMAKE_POSITION_INDEPENDENT_CODE.html) instead of BUILD_FPIC
Anyway, I'll keep poking and pushing as I see fit.
@loriab FYI: I made a sister branch (#205), instead of overwriting your work, where I eliminated almost all (1 remains) ExternalProject calls. This should make it easier to make sure the cmake state is the same (incl imported targets) throughout the project. Currently library is generated successfully but I messed something up ... config2.h.cmake.in is not found when I am configuring the generated library.
dox: at the minimum we need to update INSTALL (while at it might as well rename to INSTALL.md). End users do not seem to be OK with reading source, not sure why ;) Long-term I'd like to convert the wiki into markdown embedded into Doxygen, along the lines of what I did for TiledArray: https://valeevgroup.github.io/tiledarray/dox-master/
I'll work on a draft of INSTALL modifications
probably want to eliminate the autotools harness.
Do you mean the pkgconfig files? I've considered them harmless to generate for libxc, for example, just in case downstream wants to use autotools detection. Or do you mean configure.ac entirely? Fine by me, but this has had zero configuration and testing for C and Fortran interfaces.
some options seem to duplicate standard CMake vars ... ? should we use CMAKE_POSITION_INDEPENDENT_CODE (https://cmake.org/cmake/help/latest/variable/CMAKE_POSITION_INDEPENDENT_CODE.html) instead of BUILD_FPIC
Fine by me. BUILD_FPIC
was an option I distributed widely in my early cmake days. It may have been useful then when building both shared (w/fpic) and static (w/o) before I trusted the cmake property.
Anyway, I'll keep poking and pushing as I see fit.
Sounds great, thank you! Let me know when you'd like a psi4 integration test performed. I can do Linux and Mac by hand, but right now the only way to check Windows (without imposing on @andysim) is to have psi4's Azure generate/export/build or build.
I'll work on a draft of INSTALL modifications
OK, thanks! Can use the wiki installation guide augmented with a list of requirements CMake variables
Do you mean the pkgconfig files? I've considered them harmless to generate for libxc, for example, just in case downstream wants to use autotools detection. Or do you mean configure.ac entirely? Fine by me, but this has had zero configuration and testing for C and Fortran interfaces.
The latter: remove configure.ac entirely. There are too many issues, e.g. #204 , and I have not tries building exported libs using autotools in years.
Fine by me.
BUILD_FPIC
was an option I distributed widely in my early cmake days. It may have been useful then when building both shared (w/fpic) and static (w/o) before I trusted the cmake property.
I think we best replace
BUILD_{SHARED,STATIC}
with BUILD_SHARED_LIBS
and LIBINT2_BUILD_SHARED_AND_STATIC_LIBS
(the latter is likely used by some downstream packages)BUILD_FPIC
with CMAKE_POSITION_INDEPENDENT_CODE
Sounds great, thank you! Let me know when you'd like a psi4 integration test performed. I can do Linux and Mac by hand, but right now the only way to check Windows (without imposing on @andysim) is to have psi4's Azure generate/export/build or build.
I'm almost done with the first round of revision ... lots of work remains still (Fortran, etc.) but getting there. Thanks for getting this started!
lives on as #205
WIP
This is the start to CMake as a replacement for libtool builds. So far it builds the generator, runs it, and builds the library. That may sound like good progress, but only one set of input options examined.
closes #147