Building gbasis Fails

[FarnazH]

Setup on "macOS High Sierra" using conda environments:
Python=3.64 and 2.7.14
Cython=0.27.3
Numpy=1.14.0

Trying ./setup.py build_ext -i, you get:

Traceback (most recent call last):
  File "./setup.py", line 31, in <module>
    version=get_version(),
  File "./setup.py", line 15, in get_version
    with open('gbasis/version.py', 'r') as f:
FileNotFoundError: [Errno 2] No such file or directory: 'gbasis/version.py'

I added gbasis.version.py by hand, and then you get:

/Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/setuptools/dist.py:364: UserWarning: The version specified ('"0.1.0"') is an invalid version, this may not work as expected with newer versions of setuptools, pip, and PyPI. Please see PEP 440 for more details.
  "details." % self.metadata.version
running build_ext
cythoning gbasis/cext.pyx to gbasis/cext.cpp
building 'gbasis.cext' extension
creating build
creating build/temp.macosx-10.7-x86_64-3.6
creating build/temp.macosx-10.7-x86_64-3.6/gbasis
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Users/farnaz.heidarzadeh/anaconda3/include -arch x86_64 -I/Users/farnaz.heidarzadeh/anaconda3/include -arch x86_64 -I/Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include -I/Users/farnaz.heidarzadeh/anaconda3/include/python3.6m -c gbasis/cext.cpp -o build/temp.macosx-10.7-x86_64-3.6/gbasis/cext.o
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
In file included from /Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/ndarraytypes.h:1816:0,
                 from /Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/ndarrayobject.h:18,
                 from /Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/arrayobject.h:4,
                 from gbasis/cext.cpp:539:
/Users/farnaz.heidarzadeh/anaconda3/lib/python3.6/site-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
 #warning "Using deprecated NumPy API, disable it by " \
  ^
In file included from gbasis/gbasis.h:26:0,
                 from gbasis/cext.cpp:550:
gbasis/ints.h:26:21: fatal error: libint2.h: No such file or directory
 #include "libint2.h"
                     ^
compilation terminated.
error: command 'gcc' failed with exit status 1

[FarnazH]

P.S. I have ran ./tools/libs/install_libint-2.0.3.sh before trying to build...

[FarnazH]

P.S.S. I am trying to build using 2f8b46e commit (latest master).

[matt-chan]

Yeah... I haven't tried building gbasis recently without conda-build/Travis. I'm wondering whether we should support it at all... It would mean we don't have to try resolving the libint include madness. The old Horton setup.py was so complicated because we tried to locate it on so many systems. I really don't want to go back there. Setuptools and distutils simply aren't made to do anything more than simple dependency resolution. The downside to using conda-build (and you can run it locally) for everything is that it is a little slower (you can use tricks like --no-test and --dirty to speed it up) and that you don't get access to the source in your project directory (it doesn't use build_ext -i). Debugging becomes more of a pain because you'll have to navigate into the conda build root and modify it there. Also if a build fails you'll have to understand a bit how conda-build works to debug. The upside though is that if it works, you'll know it will probably work on everyone's machine, and it'll be well tested. Also, if you want to develop something in gbasis and test it with another module (ie chemtools), you can do that much much easier than if you compiled it yourself. Option 3 is simply to let the dev point out where the libint libraries are included and to handle the compilers themselves. It's going to be a mess for any dev that doesn't know exactly what they're doing. Once they learn the tricks of C compilers and linkers, it'll be easier and simpler, but I can imagine a new Python programmer would be absolutely bewildered. Version.py is just so that setup can figure out what the version tag is. It's supposed to be generated automatically by Travis upon release. I'll put a try except there to fallback to a default... What do you think Farnaz? I'm leaning towards conda build, with an undocumented option for option 3 if they want to work faster etc?

On Wed, Sep 19, 2018 at 11:03 AM Farnaz Heidar-Zadeh < ***@***.***> wrote: Assigned #25 <theochem/gbasis#25> to @matt-chan <https://github.com/matt-chan>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <theochem/gbasis#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA_-NaHHnPu5tAzHNl0vtTPouNqrsbDHks5uclydgaJpZM4WwVuD> .

-- Matt

…

Sent from my phone

[matt-chan]

@FarnazH I just updated the build instructions. Do they work/look okay?