Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Libint2 cmake #147

Open
loriab opened this issue Sep 16, 2019 · 2 comments
Open

Libint2 cmake #147

loriab opened this issue Sep 16, 2019 · 2 comments

Comments

@loriab
Copy link
Collaborator

loriab commented Sep 16, 2019

I see you've got an interesting hybrid of libtool and CMake for building the Libint2 compiler and library, respectively.

  • What's your feeling toward a pure CMake buildsys for the compiler?
  • Agreed that the name of the project is Libint2? (that'll be consistent with v1 and some of your CMake.)
  • Are you supporting simultaneous static/shared build because you sometimes want both or just for continuity with libtool?
  • (least important) FYI, in building the compiler on Linux, it configures and builds fine from Intel, but from GCC (7.3.0; non-standard location), I get the following:
make[3]: Entering directory `/home/psilocaluser/gits/libint2/build_gen_auto/src/bin/libint'
/home/psilocaluser/toolchainconda/envs/p4dev37b/bin/x86_64-conda_cos6-linux-gnu-c++ -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -ffunction-sections -pipe   -DHAVE_CONFIG_H  -D__COMPILING_LIBINT2=1 -I../../../src/bin -I../../../include -I/home/psilocaluser/gits/libint2/src/bin/libint/../../../include -I/home/psilocaluser/gits/libint2/src/bin/libint/../../../src/bin -I/home/psilocaluser/toolchainconda/envs/p4dev37b/include/ -I/usr/include -I. -I/home/psilocaluser/gits/libint2/src/bin/libint  -c -o build_libint.o /home/psilocaluser/gits/libint2/src/bin/libint/build_libint.cc
In file included from /home/psilocaluser/gits/libint2/src/bin/libint/purgeable.h:24:0,
                 from /home/psilocaluser/gits/libint2/src/bin/libint/singl_stack.h:29,
                 from /home/psilocaluser/gits/libint2/src/bin/libint/rr.h:33,
                 from /home/psilocaluser/gits/libint2/src/bin/libint/build_libint.cc:48:
/home/psilocaluser/gits/libint2/src/bin/libint/dgvertex.h:46:13: error: 'MemoryManager' does not name a type
     typedef MemoryManager::Address Address;
             ^~~~~~~~~~~~~
/home/psilocaluser/gits/libint2/src/bin/libint/dgvertex.h:48:13: error: 'MemoryManager' does not name a type
     typedef MemoryManager::Size Size;
             ^~~~~~~~~~~~~
/home/psilocaluser/gits/libint2/src/bin/libint/dgvertex.h:50:20: error: 'Address' was not declared in this scope
     typedef NotSet<Address> AddressNotSet;
                    ^~~~~~~
/home/psilocaluser/gits/libint2/src/bin/libint/dgvertex.h:50:27: error: template argument 1 is invalid
     typedef NotSet<Address> AddressNotSet;
                           ^
/home/psilocaluser/gits/libint2/src/bin/libint/dgvertex.h:183:5: error: 'Address' does not name a type
     Address address() const;
     ^~~~~~~
/home/psilocaluser/gits/libint2/src/bin/libint/dgvertex.h:185:28: error: 'Address' does not name a type
     void set_address(const Address& address);
                            ^~~~~~~
/home/psilocaluser/gits/libint2/src/bin/libint/dgvertex.h:247:5: error: 'Address' does not name a type
     Address address_;
     ^~~~~~~
@evaleev
Copy link
Owner

evaleev commented Sep 17, 2019

@loriab would be happy to see a PR to switch compiler build to CMake ... there are too many things on the plate to prioritize this. Ideally in-comptree library and exported library can be built using same harness.

Re: project name ... what is the recommended practice? Brief look at recent cmake's Modules/Find* suggests perhaps Qt's or Python's approaches are reasonable: be able to say find_project(Qt) and find_project(Qt4). I know that Libint1 and 2 are not compatible, but I envision the need for multiple instances of Libint2 libs in same app (e.g. host-only and device-only) or even mixing of Libint2 and Libint3 in a project. So version-specific namespaces will be the way to go.

mixed build was a PR, so a use case exists.

re: the bug ... the only idea I have is that include/libint2/util/memory.h gets included instead of src/bin/libint/memory.h? Please have a look at the preprocessed file to check.

@loriab
Copy link
Collaborator Author

loriab commented Sep 27, 2019

Great! Psi4 folks had a meetup last week and commenced the conversion from Libint1 to Libint2. Many test cases are passing. WIP at psi4/psi4#1721. I've started in on the cmake for Libint2. It's early days (can generate libint.a from repo but not even all options in yet), but I'll open the PR in case you want to comment. Will recommence discussion/questions there to keep them localized.

@loriab loriab mentioned this issue Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants