build:fallbacks_contrib
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| build:fallbacks_contrib [2018/03/01 16:05] – ↷ Page moved from developers:fallbacks_contrib to build:fallbacks_contrib Yann Pouillon | build:fallbacks_contrib [2024/10/10 07:53] (current) – external edit 127.0.0.1 | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | <WRAP important> | ||
| + | |||
| ====== Hacking the fallbacks ====== | ====== Hacking the fallbacks ====== | ||
| - | <WRAP important> | + | <WRAP important> |
| ===== Prerequisites ===== | ===== Prerequisites ===== | ||
| Line 13: | Line 15: | ||
| Unless you are an Abinit Developer, we will not provide any support regarding these topics, which are widely documented on many websites. [[https:// | Unless you are an Abinit Developer, we will not provide any support regarding these topics, which are widely documented on many websites. [[https:// | ||
| - | The best way to make the fallbacks evolve towards a direction useful to you is to [[http:// | + | The best way to make the fallbacks evolve towards a direction useful to you is to [[http:// |
| By joining the team, you commit to: | By joining the team, you commit to: | ||
| * take full care of all the data related to the packages you add to the list, including long-term maintenance; | * take full care of all the data related to the packages you add to the list, including long-term maintenance; | ||
| - | * provide support for all the packages you are responsible for and accept support | + | * provide support for all the packages you are responsible for and accept support |
| * improve the visibility and availability of the packages you are responsible for, so that they can be used as fully independent packages instead of fallbacks; | * improve the visibility and availability of the packages you are responsible for, so that they can be used as fully independent packages instead of fallbacks; | ||
| * participate to on-line and in-person meetings to globally improve the quality of Abinit and its surrounding ecosystem; | * participate to on-line and in-person meetings to globally improve the quality of Abinit and its surrounding ecosystem; | ||
| * accept that orphan packages have to be removed to maintain the overall quality of the whole. | * accept that orphan packages have to be removed to maintain the overall quality of the whole. | ||
| + | |||
| + | In exchange, you will receive help, training and collaboration from other Abinit Developers with all the issues you may encounter. | ||
| Please note that if you do not join the team, you will have to maintain your modified versions of the fallbacks on your own, including synchronization with the trunk. | Please note that if you do not join the team, you will have to maintain your modified versions of the fallbacks on your own, including synchronization with the trunk. | ||
| Line 29: | Line 33: | ||
| * be free software, [[https:// | * be free software, [[https:// | ||
| * work stand-alone and be downloadable from its own webpage; | * work stand-alone and be downloadable from its own webpage; | ||
| - | * have an Autotools-based build system; | + | * have an Autotools-based or Cmake-based build system; |
| - | * have a test suite, unit tests being a priority; | + | * have a test suite with sufficient coverage; |
| * accept debug flags; | * accept debug flags; | ||
| * be sufficiently documented to be installed and used by beginners; | * be sufficiently documented to be installed and used by beginners; | ||
| Line 36: | Line 40: | ||
| * be actually developed and maintained. | * be actually developed and maintained. | ||
| - | In particular, **at no time may the Abinit Fallbacks be considered as a substitute for the distribution of undocumented and untested low-quality | + | In particular, **at no time may the Abinit Fallbacks be considered as a substitute for the distribution of undocumented and untested low-quality code with support to be delegated to the Abinit Developers**. And since the Abinit Test Farm will be used for the validation of its portability, |
| - | Another important aspect is that a package integrated within the Abinit Fallbacks must always remain available as a fully autonomous and stand-alone package at the same time. In other words, the Abinit Fallbacks cannot substitute the normal distribution of a package, even if it comes out of Abinit. Many mature and reliable services such as [[https:// | + | Another important aspect is that a package integrated within the Abinit Fallbacks must always remain available as a fully autonomous and stand-alone package at the same time. In other words, the Abinit Fallbacks cannot substitute the normal distribution of a package, even if it comes out of Abinit. Many mature and reliable services such as [[https:// |
| Last but not least, the package must follow some conventions when installing files: | Last but not least, the package must follow some conventions when installing files: | ||
| Line 44: | Line 48: | ||
| * be able to install executables in // | * be able to install executables in // | ||
| * be able to install C headers and Fortran modules in // | * be able to install C headers and Fortran modules in // | ||
| - | * be able to install libraries in // | + | * be able to install libraries in // |
| + | * allow for staged installs, i.e. // | ||
| where //PREFIX// is the top install directory of the package. These conditions are usually fulfilled when using standard build systems. | where //PREFIX// is the top install directory of the package. These conditions are usually fulfilled when using standard build systems. | ||
| ===== Procedure ===== | ===== Procedure ===== | ||
| - | There is a standard procedure to improve the Abinit Fallbacks. It involves different levels of validation and may take a significant amount of time before the new fallbacks are fully deployed. Please expect significant delays and be prepared to contribute with the Test Farm Team all along the process | + | There is a standard procedure to improve the Abinit Fallbacks. It involves different levels of validation and may take a significant amount of time before the new fallbacks are fully deployed. Please expect significant delays and be prepared to contribute with the Test Farm Team all along the process. Once a new package has been successfully installed, providing newer versions is relatively faster. |
| - | <WRAP tip> | + | <WRAP tip> |
| Here are the different steps: | Here are the different steps: | ||
| - Clone the [[https:// | - Clone the [[https:// | ||
| - | - Implement the modifcations. | + | |
| - | - Run // | + | - Create a new branch. |
| + | | ||
| + | - Run // | ||
| - Install the new fallbacks on your computer and test Abinit with them. | - Install the new fallbacks on your computer and test Abinit with them. | ||
| - | - Go back to step 2 until step 4 succeeds. | + | - Go back to step 5 until step 6 succeeds. |
| - | - Request | + | - Submit |
| - | - Set your Abinit branch to use the new fallbacks and push it. | + | - Once merged, set your Abinit branch to use the new fallbacks and push it. |
| - | - Go back to step 2 until the builds and tests of Abinit succeed on the whole test farm. | + | |
| - | - Send a pull request to the fallbacks maintainers, | + | |
| <WRAP important> | <WRAP important> | ||
| Line 81: | Line 86: | ||
| All these steps should of course be taken as early as possible, in order to make the changes as smooth as possible for everybody. Ideally, informing and coordinating should be done when starting the project or its next development cycle, with an early reminder as the release date approaches. | All these steps should of course be taken as early as possible, in order to make the changes as smooth as possible for everybody. Ideally, informing and coordinating should be done when starting the project or its next development cycle, with an early reminder as the release date approaches. | ||
| + | |||
| ===== Enhancing the portability of a package ===== | ===== Enhancing the portability of a package ===== | ||
| Line 195: | Line 201: | ||
| If you wish to add a tricks macro for a new package, we recommend that you copy/paste the closest existing macro, automatically replace the package name in the new macro (both upper-case and lower-case), | If you wish to add a tricks macro for a new package, we recommend that you copy/paste the closest existing macro, automatically replace the package name in the new macro (both upper-case and lower-case), | ||
| + | |||
| ===== Removing a package ===== | ===== Removing a package ===== | ||
| Line 208: | Line 215: | ||
| In principle, the extremely automated build system of the fallbacks should take care of updating all the relevant information when running // | In principle, the extremely automated build system of the fallbacks should take care of updating all the relevant information when running // | ||
| + | |||
| ===== Adding a new package ===== | ===== Adding a new package ===== | ||
| Line 227: | Line 235: | ||
| Once you have provided the required enhancements, | Once you have provided the required enhancements, | ||
| + | |||
| ===== Patching a package ===== | ===== Patching a package ===== | ||
| Line 235: | Line 244: | ||
| //In any case, if you feel the need for a more sophisticated patching mechanism, then it just means that you forgot that what you actually want is to collaborate with the upstream developers of the package to fix its bugs and improve its design.// | //In any case, if you feel the need for a more sophisticated patching mechanism, then it just means that you forgot that what you actually want is to collaborate with the upstream developers of the package to fix its bugs and improve its design.// | ||
| + | |||
build/fallbacks_contrib.1519920321.txt.gz · Last modified: 2018/03/01 16:05 by Yann Pouillon