search

theochem / horton

HORTON: Helpful Open-source Research TOol for N-fermion systems
http://theochem.github.io/horton/
GNU General Public License v3.0
92 stars 40 forks source link

Get rid of setup.cfg system #234

Closed matt-chan closed 7 years ago

matt-chan commented 7 years ago

We should probably look for another solution to the setup.cfg system? It's pretty unmaintainable for the long run. All the systems keep getting updated which means we need new setup.cfgs and there's too many OSes to generate them for.

It'll be easier if we move to a C++-only toolchain and a python-only toolchain (CMake can do most of this for us!), but we'll still need something for the Cython(or pybind11) libs.

Would it make more sense to just search if the libs exist in a few generic locations (there's really only 3 or 4 options, despite the number of setup.cfgs) and let them specify environmental variables? A nicer error message if the libs aren't found (before compiling starts) would be good too. The gcc compiler doesn't give very user-friendly messages.

tovrstra commented 7 years ago

That makes a lot of sense.

tovrstra commented 7 years ago

Well, it will be very hard to detect all possible errors the compiler may make later on but we can try to detect a reasonable subset. For example, figuring out whether the correct version of LibXC is installed, may already be challenging

matt-chan commented 7 years ago

We don't need to detect the compiler error itself, but rather just conditions which cause the compiler to give an error (ie the wrong version of libXC is installed, or the atlas library is called tatlas or satlas).

It's pretty easy to check whether the file exists (tatlas/satlas) or the libxc headers (libxc version).

I agree it'll be hard to catch all of them on every system though, but I don't think there's that many possible combinations (one for debian variants, one for RHEL, maybe one for OSX). The library names rarely change themselves (I think Fedora went from atlas to tatlas/satlas in the early 20s). Does that work? CMake includes most of that functionality (not sure about checking the headers themselves). I think the only time we really need to do any dependency resolution is at the C++ (and implicitly, Cython) level?

tovrstra commented 7 years ago

Good. I agree. Would you like to implement this in our current setup.py, or should it be part of a large change of the installation process? (I'm more inclined to work in smaller steps.)

matt-chan commented 7 years ago

I think it's not worth polishing and testing our current build process, since so much of it will likely be taken apart in the next version? I don't think the CMake tests will share any common code with the setuptools tests.

Is that okay? It'll effectively be a rewrite/strip out. I'll write some example code snippets to see if it's as easy as the CMake/Pybind11 people advertise.

tovrstra commented 7 years ago

After having #249 merged, this is relatively little work, so we can fix this in 2.1.0. It will save us a lot of trouble later.