CMake for 2.6.0

[PerformanceJones]

I see no support for CMake in Version 2.6.0, despite the note that Autoconf builds are "deprecated" as of this version---is a CMake build possible; and if not, when will it be supported? I realize others have commented on this, but I saw no satisfactory replies.

[loriab]

In case you're unfamiliar, Libint2 (and many electron repulsion integrals packages) have a two-stage build: first one builds a generator executable that runs to generate code for computing ints; then second one compiles that code into a library that QC methods packages link against.

I don't know exactly the passage you refer to about "deprecated", but the present master branch uses solely autoconf for the first stage and cmake (encouraged) or autoconf (discouraged and perhaps deprecated) for the second stage.

Using cmake for both stages is in https://github.com/evaleev/libint/pull/148 and is largely working (for the C++ interface), but I don't know the merge timeline.

[PerformanceJones]

libint-2.6.0/INSTALL:

3a) build the Libint compiler, then generate and compile a library: $ make 4a) optional validation of the library: $ make check 5a) install the compiled library: $ make install

I don't see how (3a) could be split.

After (3a) I have libint2.la - isn't that what I wanted? (I am attempting to build CP2K with libint, among others.)

On Mon, Jan 04, 2021 at 09:56:38PM -0800, Lori A. Burns wrote:

In case you're unfamiliar, Libint2 (and many electron repulsion integrals packages) have a two-stage build: first one builds a generator executable that runs to generate code for computing ints; then second one compiles that code into a library that QC methods packages link against.

I don't know exactly the passage you refer to about "deprecated", but the present master branch uses solely autoconf for the first stage and cmake (encouraged) or autoconf (discouraged and perhaps deprecated) for the second stage.

Using cmake for both stages is in https://github.com/evaleev/libint/pull/148 and is largely working (for the C++ interface), but I don't know the merge timeline.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/evaleev/libint/issues/201#issuecomment-754416768

[PerformanceJones]

Hi Lori,

On Mon, Jan 04, 2021 at 09:56:38PM -0800, Lori A. Burns wrote:

In case you're unfamiliar, Libint2 (and many electron repulsion integrals packages) have a two-stage build: first one builds a generator executable that runs to generate code for computing ints; then second one compiles that code into a library that QC methods packages link against.

...So CXXGEN sets the compiler for the first stage, and CXX is for the second?

This is starting to make sense.

Best regards,

Max

[loriab]

I don't see how (3a) could be split.

Here, make builds both stages. The target make export would stop after building only the first stage and leave you with a tarball of generated source code, iirc.

This works all in autoconf because you're building libint like any other software package -- from repo to library on one computer. The tricky thing about Libint (or simint) is that usually one person generates the tarball once on one computer. Then lots of people use that tarball to build the library on different computers, so configuration needs to happen at both stages. It was the latter setup I was describing with 1: autoconf only + 2: cmake preferred. This breakdown may be helpful.

cp2k is all standard orderings, I think I've read. Could you use a pre-generated tarball from https://github.com/evaleev/libint/releases/tag/v2.6.0 so you could focus on the l2+cp2k side and use cmake?

...So CXXGEN sets the compiler for the first stage, and CXX is for the second?

I've never built with autoconf and split compilers, but that sounds about right.

[PerformanceJones]

On Tue, Jan 05, 2021 at 07:09:14AM -0800, Lori A. Burns wrote:

I don't see how (3a) could be split.

Here, make builds both stages. The target make export would stop after building only the first stage and leave you with a tarball of generated source code, iirc.

Aha - thank you!

This works all in autoconf because you're building libint like any other software package -- from repo to library on one computer. The tricky thing about Libint (or simint) is that usually one person generates the tarball once on one computer. Then lots of people use that tarball to build the library on different computers, so configuration needs to happen at both stages. It was the latter setup I was describing with 1: autoconf only + 2: cmake preferred. This breakdown may be helpful.

This implies that after "make export" I would find CMakeLists.txt.

cp2k is all standard orderings, I think I've read. Could you use a pre-generated tarball from https://github.com/evaleev/libint/releases/tag/v2.6.0 so you could focus on the l2+cp2k side and use cmake?

It would depend on the target; I need to be prepared to build applications on "non-standard" hardware. Also I like to have full control over any linked libraries, for performance reaons.

...So CXXGEN sets the compiler for the first stage, and CXX is for the second?

I've never built with autoconf and split compilers, but that sounds about right.

My thinking was to save more aggressive options for the second stage, because the performance of libint2 is of more concern than the time to create it. :)

Thank you!

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/evaleev/libint/issues/201#issuecomment-754694605

[loriab]

This implies that after "make export" I would find CMakeLists.txt.

I think you should find a tarball after make export. Once it's moved somewhere else and unpacked, should be a CMakeLists.txt that's derived from https://github.com/evaleev/libint/blob/master/export/cmake/CMakeLists.txt.export .

It would depend on the target; I need to be prepared to build applications on "non-standard" hardware. Also I like to have full control over any linked libraries, for performance reasons.

I definitely understand -- I wrote the cmake b/c I wanted control and couldn't bear autoconf :-) . But most non-standard hardware should need edits at the exported CMakeLists.txt level, not at the generating-the-code level (though certainly build edits should be backported to the repo). That is, I think the v2.6 tarball of generated source could be edited (build files, header ifdef's) to build on Windows w/o real changes to the generated ints code.

You need the Fortran interface, right? Windows eventually? I ask because master won't do Windows, but #148 won't do Fortran (yet) but is far easier to construct an extensive build matrix (like it sounds you are contemplating) around. Hence I wonder whether an initial Linux foray of l2 tarball from master + cp2k to get it working, followed by building out the cmake-only branch to suit your broader needs, might be a good path.

My thinking was to save more aggressive options for the second stage, because the performance of libint2 is of more concern than the time to create it. :)

👍 Though I believe that the code is already well-optimized, and there is less (besides arch) for the compiler to do.

[PerformanceJones]

Please see interposed responses.

On Tue, Jan 05, 2021 at 08:09:45AM -0800, Lori A. Burns wrote:

This implies that after "make export" I would find CMakeLists.txt.

I think you should find a tarball after make export. Once it's moved somewhere else and unpacked, should be a CMakeLists.txt that's derived from https://github.com/evaleev/libint/blob/master/export/cmake/CMakeLists.txt.export .

It would depend on the target; I need to be prepared to build applications on "non-standard" hardware. Also I like to have full control over any linked libraries, for performance reasons.

I definitely understand -- I wrote the cmake b/c I wanted control and couldn't bear autoconf :-) . But most non-standard hardware should need edits at the exported CMakeLists.txt level, not at the generating-the-code level (though certainly build edits should be backported to the repo). That is, I think the v2.6 tarball of generated source could be edited (build files, header ifdef's) to build on Windows w/o real changes to the generated ints code.

You need the Fortran interface, right? Windows eventually? I ask because master won't do Windows, but #148 won't do Fortran (yet) but is far easier to construct an extensive build matrix (like it sounds you are contemplating) around. Hence I wonder whether an initial Linux foray of l2 tarball from master + cp2k to get it working, followed by building out the cmake-only branch to suit your broader needs, might be a good path.

Definitely NOT Windows!!! Only Linux (or *nix).

I often work on bare-metal systems (e.g. in a cloud), and have to build even my compiler from scratch. :)

My thinking was to save more aggressive options for the second stage, because the performance of libint2 is of more concern than the time to create it. :)

👍 Though I believe that the code is already well-optimized, and there is less (besides arch) for the compiler to do.

Well, I'm trying O2 for CXXGEN and O3 for CXX (using GCC for the first attempts). With ICC or others, I'd try a number of more exotic possibilities - eventually.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/evaleev/libint/issues/201#issuecomment-754732951

[evaleev]

cmake harness for the compiler will be provided by #205