Closed loriab closed 5 years ago
looks good. do I need to bump the version?
Thanks for the merge. There's Ninja, Windows, and pkgconfig changes since v1.2.1, so a version bump is justifiable but not necessary on Psi's account -- your call.
Ok just wanted to make sure that you guys don't rely on semantic versioning for tracking libint dependency.
On Sat, Apr 6, 2019, 9:31 AM Lori A. Burns notifications@github.com wrote:
Thanks for the merge. There's Ninja, Windows, and pkgconfig changes since v1.2.1, so a version bump is justifiable but not necessary on Psi's account -- your call.
— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/evaleev/libint/pull/120#issuecomment-480504364, or mute the thread https://github.com/notifications/unsubscribe-auth/ACF0Z86cyEb7OadyT2L3bbF-PU2v7xSMks5veKGxgaJpZM4cf6PG .
A packager wanted this (https://github.com/psi4/psi4/issues/1589) so that a CMake-built libint can be detected by both cmake and libtool downstream buildsystems. The CMake
LibintConfig.cmake
and friends are too involved to be imitated by libtool.I constructed the
.pc
file by analogy to Libxc https://gitlab.com/libxc/libxc/blob/master/cmake/libxc.pc.in and https://gitlab.com/libxc/libxc/blob/master/build/libxc.pc.in . It builds and looks like the below, but I haven't tried out its consumption in a downstream libtool build.