plumed
Cmake
Description
I set up the CMake build generator: it mimic the build process that calls make install-build in the src/lib directory, but not yet the install procedure of the original autoconf.
It seems compiles plumed, plumed-static and plumed-runtime correctly, but I need to see if it works in a mac environment
It can survive in parallel with autoconf and, for user like me used to vscode, may also be useful for some QoL integration with some IDEs.
This branch still need some love:
- [ ] Tests
- [ ] CI and CI tests
- [ ] implementation of all of the options from autoconf
- [ ] installation procedure
- [ ] I don't know if the copyright statements should also go in the CMakeLists.txt files I think it should remain a draft until these are not completed
Target release
I think this should aim to be in the next release, even if it does not touch the actual code
Type of contribution
- [X] Added a new build procedure
Tests
- [ ] I added a new regtest or modified an existing regtest to validate my changes.
- [ ] I verified that all regtests are passed successfully on GitHub Actions.
@Iximiel great!
I would suggest adding one thing to the todo list, which is possibility to compile plumed using pip. I know that for cmake projects this should be feasible (you can install cmake itself from pip).
Currently, in conda and macports we have two separate packages:
conda (or macports) install plumedwith the library and executableconda (or macports) install py-plumedwith the python wrappers (it then loads at runtime the library)
In pip instead we have:
pip install plumedwith the python wrappers, and you need to install the library on your own.
It would be nice to have instead something like:
pip install py-plumedwith the python wrapperspip install plumedlibwith the librarypip install plumedwhich depends on both
This would allow people using pip to have a fully working plumed package without the need to separately compile plumed.
Regarding tests, I guess you will have to add a new job in the github action file.
Codecov Report
Patch coverage: 100.00% and project coverage change: +0.06 :tada:
Comparison is base (
aadcb7e) 85.73% compared to head (1cea136) 85.79%.
:exclamation: Current head 1cea136 differs from pull request most recent head 56ea9e9. Consider uploading reports for the commit 56ea9e9 to get more accurate results
:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@ Coverage Diff @@
## master #934 +/- ##
==========================================
+ Coverage 85.73% 85.79% +0.06%
==========================================
Files 600 600
Lines 53472 54727 +1255
==========================================
+ Hits 45843 46953 +1110
- Misses 7629 7774 +145
| Impacted Files | Coverage Δ | |
|---|---|---|
| src/crystallization/EnvironmentSimilarity.cpp | 94.06% <ø> (+0.02%) |
:arrow_up: |
| src/drr/DRR.h | 100.00% <ø> (ø) |
|
| src/tools/Communicator.h | 89.47% <ø> (ø) |
|
| src/tools/SwitchingFunction.cpp | 95.95% <ø> (+0.14%) |
:arrow_up: |
| src/ves/TD_Multicanonical.cpp | 96.53% <ø> (+0.10%) |
:arrow_up: |
| src/ves/TD_Uniform.cpp | 98.11% <ø> (+0.11%) |
:arrow_up: |
| src/bias/MetaD.cpp | 87.95% <100.00%> (+0.39%) |
:arrow_up: |
| src/drr/DRR.cpp | 93.33% <100.00%> (+0.81%) |
:arrow_up: |
| src/drr/DynamicReferenceRestraining.cpp | 90.55% <100.00%> (+0.29%) |
:arrow_up: |
| src/drr/drrtool.cpp | 93.44% <100.00%> (-1.87%) |
:arrow_down: |
| ... and 5 more |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
If we keep this in the repository it will go out of sync very soon. Doesn’t cmake allow to use wildcards?
Il giorno mer 10 mag 2023 alle 16:58 Daniele @.***> ha scritto:
@.**** commented on this pull request.
In src/analysis/CMakeLists.txt https://github.com/plumed/plumed2/pull/934#discussion_r1190039416:
@@ -0,0 +1,36 @@ +#automatically generated CMakeLists.txt, may not work!
the base file is "automatically generated" by a homemade sh script (that I'm in doubt of including or not in the repository), but the ADDMODULEDEPENDENCIES macro arguments are them manually changed. This because I wanted to reduce the "dependencies entanglement" and some circular dependency tree that exist if we use the list of dependencies in the "USE=" from the original Makefile (like core and tools). I forgot to remove the lines "#automatically generated CMakeLists.txt, may not work!".
— Reply to this email directly, view it on GitHub https://github.com/plumed/plumed2/pull/934#discussion_r1190039416, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBNCXVSQQKJM534Y2YZ5XDXFOUIFANCNFSM6AAAAAAX4SF6BY . You are receiving this because you commented.Message ID: @.***>
-- Sent from Gmail mobile
If we keep this in the repository it will go out of sync very soon. Doesn’t cmake allow to use wildcards?
yes, we can use wildcard for getting the sources, but (source):
Note : We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed then the generated build system cannot know when to ask CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on all generators, or if a new generator is added in the future that cannot support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS works reliably, there is still a cost to perform the check on every rebuild.
How much is the additional cost to do the check at every rebuild? Would it be possible to make automatically?
Ideally, automatically when doing "make" (as it is now). Alternatively when configuring with "cmake"
If you change a source file, the cost is the very like the same of automake, It needs to update the object and eventually relink it to it's archive or library.
If you change the cmakelist, if you are working on an IDE you'll have the makefiles regenerated and ready to build as soon you save the cmakelist, without the initial configuration, if you are working by hand you can call cmake --build . in the builld directory and if necessary will configure and generate the files to pass to make, and then call make to build the project
I see. Then can we perhaps have empty lists in the files stored on GitHub? If I understand correctly, the build system will then generate them when the users build.
Sorry for being picky on this but I think it's a bad idea to store files that should be generated automatically. We have an exception (./configure) because generating it from the source (./configure.ac) requires the user to install autoconf. By storing ./configure the user does not need to install anything (this is possibly the unique advantage of autoconf wrt cmake).
However, to make sure that ./configure and ./configure.ac are in sync, we have a specific test. And consider that ./configure.ac changes much more rarely than the number of times we add new .cpp files.
So, if you have to include those lists, I think somewhere on GitHub actions you have to check if they are consistent with the included file. And we will have to pay the price that whenever we add a new file we have to add it to the list or we receive an error.
Still I think that the best solution is not to include those lists.
If you change a source file, the cost is the very like the same of automake, It needs to update the object and eventually relink it to it's archive or library. If you change the cmakelist, if you are working on an IDE you'll have the makefiles regenerated and ready to build as soon you save the cmakelist, without the initial configuration, if you are working by hand you can call
cmake --build .in the builld directory and if necessary will configure and generate the files to pass to make, and then call make to build the project
I see the point, having the list explicitly stored means you have to keep track of it and update the list in the right file each time you add one or more files.
In my opinion if you explicitly list the object in the Makefile or the sources in the CMakeLists.txt you have more control on you code.
We can add a consistency check for the various CMakeLists.txt in the main Makefile.
Just to be clear: the CMakeLists.txt are not created by the cmake generation process, they are created by a script, and the header "#automatically generated CMakeLists.txt, may not work!" is a reminder set by me, for the developer that has set up the make module and want to add it as a cmake module.
I'm adding that script in the maketools directory, or in a more appropriate directory