mbox series

[RFC,0/4] One versionfile to rule them all...

Message ID 20190307115448.54041-1-bruce.richardson@intel.com (mailing list archive)
Headers
Series One versionfile to rule them all... |

Message

Bruce Richardson March 7, 2019, 11:54 a.m. UTC
  Right now with DPDK we have two sources of version information - the
rte_version.h header file containing macros for C use, and the project
version number in the project definition in meson.build. This is not
optimal, so this patchset aims to provide a single source for the DPDK
version. The options considered are:

* Keep version info in rte_version.h only. The two reasons this was not
  chosen were:
  1) parsing the version number from the header is awkward, as seen in the
     rte.sdkconfig.mk file, and a script to do so would be needed to
     integrate that into the meson build project definition.
  2) rte_version.h is not in an obvious location inside the project when
     a user clones from git. It's hidden away in the
     "lib/librte_eal/common/include" folder. Ideally the version number
     should be evident at the top level of the DPDK tree.

* Keep version info in meson.build file only. This seemed a better option
  than keeping the info in rte_version.h, but it still had disadvantages:
  1) For make, using grep on meson.build to extract the version seemed a
     bit awkward, though doable. Splitting the version was tricky too, but
     managable with a small amount of scripting.
  2) There was no easy way to have users access the version number when
     "make showversion" was deprecated with the make build system.

* Store the version number in a new version file at the root level of the
  repo.
  * This did have the advantage of being easily discoverable on clone
  * Still had the disadvantage of needing some parsing to generate the
    defines from rte_version.h

Since the last option seemed best, that is what is implemented in this set.
The file DPDK_VERSION is added to store the version number, and make and
meson both use that as their source of version info. For C code, the
rte_version.h header remains, except that the basic definitions of the
release YEAR, MONTH, MINOR etc. are moved to be automatically generated as
part of rte_config.h. For make builds, this is done via using the
preprocessor to insert the values when it generates the config. For meson
builds, this is done by just adding the values to the dpdk_conf
configuration object.

Bruce Richardson (4):
  build: add single source of DPDK version number
  build: use version number from config file
  build: move meson version handling to config directory
  eal: remove unneeded version logic

 DPDK_VERSION                                |  1 +
 config/common_base                          | 14 ++++++++
 config/meson.build                          | 26 +++++++++++++++
 config/rte_config.h                         |  5 +++
 lib/librte_eal/common/include/rte_version.h | 36 +--------------------
 meson.build                                 | 14 +-------
 mk/rte.sdkconfig.mk                         | 18 +++--------
 7 files changed, 52 insertions(+), 62 deletions(-)
 create mode 100644 DPDK_VERSION
  

Comments

Luca Boccassi March 7, 2019, 12:09 p.m. UTC | #1
On Thu, 2019-03-07 at 11:54 +0000, Bruce Richardson wrote:
> Right now with DPDK we have two sources of version information - the
> rte_version.h header file containing macros for C use, and the
> project
> version number in the project definition in meson.build. This is not
> optimal, so this patchset aims to provide a single source for the
> DPDK
> version. The options considered are:
> 
> * Keep version info in rte_version.h only. The two reasons this was
> not
>   chosen were:
>   1) parsing the version number from the header is awkward, as seen
> in the
>      rte.sdkconfig.mk file, and a script to do so would be needed to
>      integrate that into the meson build project definition.
>   2) rte_version.h is not in an obvious location inside the project
> when
>      a user clones from git. It's hidden away in the
>      "lib/librte_eal/common/include" folder. Ideally the version
> number
>      should be evident at the top level of the DPDK tree.
> 
> * Keep version info in meson.build file only. This seemed a better
> option
>   than keeping the info in rte_version.h, but it still had
> disadvantages:
>   1) For make, using grep on meson.build to extract the version
> seemed a
>      bit awkward, though doable. Splitting the version was tricky
> too, but
>      managable with a small amount of scripting.
>   2) There was no easy way to have users access the version number
> when
>      "make showversion" was deprecated with the make build system.
> 
> * Store the version number in a new version file at the root level of
> the
>   repo.
>   * This did have the advantage of being easily discoverable on clone
>   * Still had the disadvantage of needing some parsing to generate
> the
>     defines from rte_version.h
> 
> Since the last option seemed best, that is what is implemented in
> this set.
> The file DPDK_VERSION is added to store the version number, and make
> and
> meson both use that as their source of version info. For C code, the
> rte_version.h header remains, except that the basic definitions of
> the
> release YEAR, MONTH, MINOR etc. are moved to be automatically
> generated as
> part of rte_config.h. For make builds, this is done via using the
> preprocessor to insert the values when it generates the config. For
> meson
> builds, this is done by just adding the values to the dpdk_conf
> configuration object.
> 
> Bruce Richardson (4):
>   build: add single source of DPDK version number
>   build: use version number from config file
>   build: move meson version handling to config directory
>   eal: remove unneeded version logic
> 
>  DPDK_VERSION                                |  1 +
>  config/common_base                          | 14 ++++++++
>  config/meson.build                          | 26 +++++++++++++++
>  config/rte_config.h                         |  5 +++
>  lib/librte_eal/common/include/rte_version.h | 36 +----------------
> ----
>  meson.build                                 | 14 +-------
>  mk/rte.sdkconfig.mk                         | 18 +++--------
>  7 files changed, 52 insertions(+), 62 deletions(-)
>  create mode 100644 DPDK_VERSION

Series-acked-by: Luca Boccassi <bluca@debian.org>

This is a good change, thanks for that. Too bad there's not yet a meson
--project-version option - it's been discussed but not implemented:

https://github.com/mesonbuild/meson/issues/3535
  
Bruce Richardson March 7, 2019, 12:14 p.m. UTC | #2
On Thu, Mar 07, 2019 at 12:09:44PM +0000, Luca Boccassi wrote:
> On Thu, 2019-03-07 at 11:54 +0000, Bruce Richardson wrote:
> > Right now with DPDK we have two sources of version information - the
> > rte_version.h header file containing macros for C use, and the project
> > version number in the project definition in meson.build. This is not
> > optimal, so this patchset aims to provide a single source for the DPDK
> > version. The options considered are:
> > 
> > * Keep version info in rte_version.h only. The two reasons this was not
> > chosen were: 1) parsing the version number from the header is awkward,
> > as seen in the rte.sdkconfig.mk file, and a script to do so would be
> > needed to integrate that into the meson build project definition.  2)
> > rte_version.h is not in an obvious location inside the project when a
> > user clones from git. It's hidden away in the
> > "lib/librte_eal/common/include" folder. Ideally the version number
> > should be evident at the top level of the DPDK tree.
> > 
> > * Keep version info in meson.build file only. This seemed a better
> > option than keeping the info in rte_version.h, but it still had
> > disadvantages: 1) For make, using grep on meson.build to extract the
> > version seemed a bit awkward, though doable. Splitting the version was
> > tricky too, but managable with a small amount of scripting.  2) There
> > was no easy way to have users access the version number when "make
> > showversion" was deprecated with the make build system.
> > 
> > * Store the version number in a new version file at the root level of
> > the repo.  * This did have the advantage of being easily discoverable
> > on clone * Still had the disadvantage of needing some parsing to
> > generate the defines from rte_version.h
> > 
> > Since the last option seemed best, that is what is implemented in this
> > set.  The file DPDK_VERSION is added to store the version number, and
> > make and meson both use that as their source of version info. For C
> > code, the rte_version.h header remains, except that the basic
> > definitions of the release YEAR, MONTH, MINOR etc. are moved to be
> > automatically generated as part of rte_config.h. For make builds, this
> > is done via using the preprocessor to insert the values when it
> > generates the config. For meson builds, this is done by just adding the
> > values to the dpdk_conf configuration object.
> > 
> > Bruce Richardson (4): build: add single source of DPDK version number
> > build: use version number from config file build: move meson version
> > handling to config directory eal: remove unneeded version logic
> > 
> >  DPDK_VERSION                                |  1 + config/common_base
> >  | 14 ++++++++ config/meson.build                          | 26
> >  +++++++++++++++ config/rte_config.h                         |  5 +++
> >  lib/librte_eal/common/include/rte_version.h | 36 +----------------
> >  ---- meson.build                                 | 14 +-------
> >  mk/rte.sdkconfig.mk                         | 18 +++-------- 7 files
> >  changed, 52 insertions(+), 62 deletions(-) create mode 100644
> >  DPDK_VERSION
> 
> Series-acked-by: Luca Boccassi <bluca@debian.org>
> 
> This is a good change, thanks for that. Too bad there's not yet a meson
> --project-version option - it's been discussed but not implemented:
> 
> https://github.com/mesonbuild/meson/issues/3535
> 
Yes, I saw that request, and considered looking into doing it. However,
even when it is implemented, we wouldn't be able to base anything on it
till our next meson version bump at the earliest. Therefore I felt the most
effective solution is one based in DPDK itself.