Closed robertodr closed 6 years ago
Awesome work! Thank you!
I browsed through the changes - looks very good. Looking forward to having this in.
:exclamation: No coverage uploaded for pull request base (
master@885b23a
). Click here to learn what that means. The diff coverage is50.81%
.
@@ Coverage Diff @@
## master #59 +/- ##
=========================================
Coverage ? 42.29%
=========================================
Files ? 78
Lines ? 1785
Branches ? 0
=========================================
Hits ? 755
Misses ? 1030
Partials ? 0
Impacted Files | Coverage Δ | |
---|---|---|
src/functionals/b97c.hpp | 0% <ø> (ø) |
|
src/functionals/b97xc.hpp | 0% <ø> (ø) |
|
src/functionals/pbeintx.cpp | 0% <0%> (ø) |
|
src/functionals/tw.cpp | 0% <0%> (ø) |
|
src/functionals/pbex.hpp | 70% <0%> (ø) |
|
src/functionals/pw86x.cpp | 0% <0%> (ø) |
|
src/functionals/revtpssx_eps.hpp | 0% <0%> (ø) |
|
src/functionals/pbesolx.cpp | 0% <0%> (ø) |
|
src/functionals/optx.cpp | 0% <0%> (ø) |
|
src/functionals/m06x2c.cpp | 0% <0%> (ø) |
|
... and 66 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update 885b23a...45e716b. Read the comment docs.
The issue with the option
command wrappers is an Autocmake issue and will be addressed separately.
Is this ready to go from your perspective Roberto?
Because it looks good and ready from my perspective. Big gold star for all the work!
Yes, it is ready. But it's quite large and I'd like to have another set of eyes poking around.
OK but I am sure it's better than before and since it is gigantic, not easy to review but I will scroll through things. I prefer smaller PRs :-)
Yeah the PR snowballed. But I couldn't see a way of chunkyfying it better...
It's awesome work. Once Travis is happy, I will merge :-) Thank you!
This is ready for review. I have mostly moved stuff around, trying to localize the scope of CMake variables as much as possible. I haven't written any documentation. I believe that can be fixed at a later stage since the number of files changed is already quite large. Once this is reviewed and approved, I can squash some of the commits to provide a more concise history. Merging will fix #34. This is a list of what I have done:
fortran
folderpython
folder. Warning Even before this change I was not able to get the Python bindings test to work.test
folder.Makefile
-s.CONTRIBUTING.md
,ISSUE_TEMPLATE.md
,PULL_REQUEST_TEMPLATE.md
andCODEOWNERS
).travis.yml
and.appveyor.yml
src
folder.find_package(XCFun)
. ~Needs thorough testing~Possibly BREAKING change
Instead of compiling the Fortran module into a library and shipping the (compiler-dependent)
.mod
file, the Fortran source file is always configured and copied into the binary tree (install rules are also present and the file is always installed alongside the headers). The host program that needs the Fortran bindings will have to compile this file.Installation folder layout
Use of the CMake config module
This idiotic C++ example can be configured doing:
and CMake will find XCFun on the system.
with the source file
use_xcfun.cpp
:I assume the same works for Fortran, but I haven't tried.