dev:starting
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revision | |||
| dev:starting [2022/12/16 09:27] – Fix link krack | dev:starting [2026/10/14 08:46] (current) – fstein | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Starting development ====== | ====== Starting development ====== | ||
| - | CP2K invites the community to contribute to its development! | + | This page has been moved to [[https://manual.cp2k.org/trunk/ |
| - | Documentation improvements, | + | |
| - | + | ||
| - | CP2K is a large project, there is no way to study the full code, and start when that is done! Start working on small patches first, that are easy to code, to test and to integrate. Small patches are easier to review and thus will be more quickly merged to the Git master branch. As experience with the code grows, tackling larger projects becomes realistic. Developers who contribute regularly | + | |
| - | + | ||
| - | ===== Prepare the patch ===== | + | |
| - | + | ||
| - | - Fork the CP2K Repository on GitHub via " | + | |
| - | - Even as a member of the development team you will not be able to push directly to the `master` branch of the https:// | + | |
| - | - On your machine, clone the repository via **git clone %%--%%recursive https:// | + | |
| - | - Change into the created cp2k directory: **cd cp2k** | + | |
| - | - Start working in a new branch: **git checkout -b my-new-feature** | + | |
| - | - Make your changes to the code | + | |
| - | - Add new and changed files: **git add ...** | + | |
| - | - Commit the changes: **git commit** | + | |
| - | - Please follow the [[https:// | + | |
| - | - Do the first push to your fork, give the remote branch the same name as the local one: **git push -u origin my-new-feature** | + | |
| - | - Do some more work, then repeat point 6. and 7. | + | |
| - | - Push your new changes to the remote repository via **git push** (note: the '-u origin my-new-feature' | + | |
| - | - Use the GitHub interface at https:// | + | |
| - | + | ||
| - | ===== Update your copy of the master/ | + | |
| - | + | ||
| - | - To update the ' | + | |
| - | - tell your local git repository once about the remote: **git remote add upstream https:// | + | |
| - | - make sure you are on the right branch: **git checkout master** | + | |
| - | - ' | + | |
| - | - To update a branch with patches onto the updated master branch: | + | |
| - | - **git checkout my-new-feature** | + | |
| - | - **git rebase master**, this may generate rebase/ | + | |
| - | - after a rebase of a branch with commits which was already pushed to a remote, you have to force-push: **git push %%--%%force** | + | |
| - | + | ||
| - | ===== Submit the patch ===== | + | |
| - | + | ||
| - | Following these guidelines will avoid common mistakes and make it easier to integrate patches. It usually takes less than one hour: | + | |
| - | + | ||
| - | - **make -j pretty** to auto-format the code (variables). | + | |
| - | - **make -j ARCH=... VERSION=" | + | |
| - | - prepare and add testcases suitable for regtesting the code (i.e. that run quickly through all new code paths) | + | |
| - | - run these testcases by hand. Be sure to use bounds checking, and valgrind to check for undefined variables or memory leaks (see debug page) | + | |
| - | - run the full [[dev: | + | |
| - | - pay attention | + | |
| - | - are new files, including tests, visible ? Use 'git add' as needed. | + | |
| - | - Are only the intended files and code modified ? Use 'git revert' | + | |
| - | - Does the code contain stray write statements or debug info ? | + | |
| - | - Is all new code sufficiently documented and explained ? | + | |
| - | - Are the input keywords clearly described ? | + | |
| - | - Are proper citations added the bibliography ? | + | |
| - | - if any of the above steps required changes to the code, go back to the first step, otherwise go to the next step. | + | |
| - | - go to https:// | + | |
| - | - you can check the status of your PR at https:// | + | |
| - | - we use ' | + | |
| - | - the PR will trigger the [[https:// | + | |
| - | - In the case of success, the PR will be merged by one of the CP2K administrators | + | |
| - | - In the case of error, please check what's wrong in the CI logs, fix it in your branch, and commit/push again. The CI will automatically rerun on the new version of the code (no need to close the PR, it will be automatically updated!). Repeat until the CI runs fine. | + | |
| - | + | ||
| - | ===== Prepare a development | + | |
| - | + | ||
| - | The HPC package manager [[https://spack.io/|Spack]] can be used to provide a development environment for CP2K. | + | |
| - | + | ||
| - | <note important> | + | |
| - | + | ||
| - | - change into the CP2K directory: '' | + | |
| - | - create a Spack environment (here for building an '' | + | |
| - | - activate the Spack environment using: '' | + | |
| - | - install everything required for CP2K and build & install CP2K from the current source tree (this may take while): '' | + | |
| - | - start a new shell with all the environment variables set using '' | + | |
| - | - to recompile, run: '' | + | |
| - | + | ||
| - | If you experience problems with other tools (like your editor) when inside the Spack environment, | + | |
dev/starting.txt · Last modified: by fstein
