|
| 1 | +The versioninfo mechanism |
| 2 | +========================= |
| 3 | + |
| 4 | +This describes the versioninfo mechanism which automatically generates |
| 5 | +the version information for use in `configure.ac` and then the rest of |
| 6 | +the autotools build system. |
| 7 | + |
| 8 | + |
| 9 | +The basic idea |
| 10 | +-------------- |
| 11 | + |
| 12 | +The main goals are |
| 13 | + |
| 14 | + * Avoid the need for avrdude maintainers to edit the avrdude version |
| 15 | + in the autotools buildsystem's `configure.ac` in addition to the |
| 16 | + cmake buildsystem's main `CMakeLists.txt` file. |
| 17 | + |
| 18 | + * Have the autotools buildsystem generate the same version message as |
| 19 | + the cmake buildsystem in both the `avrdude.conf` file and the |
| 20 | + `avrdude -?` output version message. |
| 21 | + |
| 22 | +To achieve this, we need to replicate some of the logic from the |
| 23 | +top-level `CMakeLists.txt` which creates the `AVRDUDE_FULL_VERSION` |
| 24 | +variable. |
| 25 | + |
| 26 | +We run this logic mostly at bootstrap/autoreconf time, with the |
| 27 | +`configure` propagating the information, so that some `make` time |
| 28 | +checks can determine whether the bootstrap code needs to be re-run, |
| 29 | +and re-run it automatically if possible. |
| 30 | + |
| 31 | + |
| 32 | +All the different build types |
| 33 | +----------------------------- |
| 34 | + |
| 35 | +There are many ways to build avrdude. |
| 36 | + |
| 37 | +There are three types of source trees: |
| 38 | + |
| 39 | + * a git clone's working directory with a `.git/` directory |
| 40 | + |
| 41 | + * an extracted GitHub tarball/zipfile (contains the same as a git |
| 42 | + clone's working directory, but no `.git/` directory with its |
| 43 | + associated git commit information) |
| 44 | + |
| 45 | + * from a dist tarball as generated by the autotools buildsystem's |
| 46 | + `make dist` or `make distcheck` commands (contains the required |
| 47 | + git commit information inside the versioninfo-stamp file) |
| 48 | + |
| 49 | +In any of these cases, this can be an avrdude release or non-release, |
| 50 | +determined by whether the latest commit's hash is equal to the latest |
| 51 | +tag's commit's hash (`GIT_COMMIT_HASH == GIT_TAG_HASH`). |
| 52 | + |
| 53 | +In principle, any of these source types could be built with either the |
| 54 | +cmake buildsystem or the autotools buildsystem. With `configure.ac` |
| 55 | +being rooted in the `src/` subdirectory though, the dist tarball |
| 56 | +generated by `make dist` cannot contain files outside of `src/` which |
| 57 | +are required for a cmake build. |
| 58 | + |
| 59 | +In all types of builds, we want the same version message when building |
| 60 | +using the autotools buildsystem as the cmake buildsystem creates: |
| 61 | + |
| 62 | + * `7.3` for a release |
| 63 | + * `7.3-20240213 (9634fd15)` with commit date and commit hash for a |
| 64 | + non-release. |
| 65 | + |
| 66 | +If we abbreviate those types of version messages with `R` for release |
| 67 | +and `H` for hash, we can put all cases into a table. `BS` stands for |
| 68 | +buildsystem, obviously. |
| 69 | + |
| 70 | +``` |
| 71 | + Version_Message |
| 72 | +SOURCE TYPE BS Release? Wanted Actual |
| 73 | +git clone wd cm yes R R |
| 74 | +git clone wd cm no H H |
| 75 | +github tarball cm yes R R |
| 76 | +github tarball cm no H R (wrong/missing info) |
| 77 | +dist tarball cm yes R cmake build N/A at this time |
| 78 | +dist tarball cm no H cmake build N/A at this time |
| 79 | +
|
| 80 | +git clone wd am yes R R |
| 81 | +git clone wd am no H H |
| 82 | +github tarball am yes R R |
| 83 | +github tarball am no H R (wrong/missing info/like cmake) |
| 84 | +dist tarball am yes R R |
| 85 | +dist tarball am no H H |
| 86 | +``` |
| 87 | + |
| 88 | +As the github tarball (like the github zipfile) does not contain any |
| 89 | +commit/tag information, it is impossible for any buildsystem to |
| 90 | +determine whether building a release or non-release. |
| 91 | + |
| 92 | +The dist tarball generated by the autotools buildsystem's `make dist` |
| 93 | +does contain the commit/tag information, so builds from such a dist |
| 94 | +tarball can correctly determine whether they are building a release or |
| 95 | +a non-release source tree. However, only builds using the autotools |
| 96 | +buildsystem are possible as long as the `configure.ac` file is located |
| 97 | +inside the `src/` subdirectory instead of the top-level directory. |
| 98 | + |
| 99 | + |
| 100 | +The `build-helpers/versioninfo.sh` script file |
| 101 | +---------------------------------------------- |
| 102 | + |
| 103 | +The `versioninfo.sh` script tries to determine the version and git |
| 104 | +information from the raw sources: |
| 105 | + |
| 106 | + * The version number (`7.3`) is determined from the top-level |
| 107 | + `CMakeLists.txt` file's `project(... VERSION ...)` line. |
| 108 | + |
| 109 | + * The information on the latest git commit date and hash and git tag |
| 110 | + hash is determined from the `.git/` subdirectory corresponding to |
| 111 | + the top-level `CMakeLIsts.txt` file. |
| 112 | + |
| 113 | +The `versioninfo.sh` script then prints these items, one per line. |
| 114 | + |
| 115 | + |
| 116 | +The `build-helpers/versioninfo.m4` m4 include file |
| 117 | +-------------------------------------------------- |
| 118 | + |
| 119 | +TODO: Write text. |
| 120 | + |
| 121 | + |
| 122 | +The `build-helpers/versioninfo.mk` Makefile include file |
| 123 | +-------------------------------------------------------- |
| 124 | + |
| 125 | +TODO: Write text. |
| 126 | + |
| 127 | + |
| 128 | +The `configure.ac` file |
| 129 | +----------------------- |
| 130 | + |
| 131 | +TODO: Write text. |
| 132 | + |
| 133 | + |
| 134 | +The `GNUmakefile.in` and `GNUmakefile` files |
| 135 | +-------------------------------------------- |
| 136 | + |
| 137 | +If you are running GNU make, the `GNUmakefile` file generated from the |
| 138 | +`GNUmakefile.in` file will update the versioninfo automatically before |
| 139 | +executing any possible make recipes. |
| 140 | + |
| 141 | +If you are not running GNU make, you will need to run the command to |
| 142 | +update the versioninfo update command manually. You will be shown that |
| 143 | +command if necessary. |
0 commit comments