From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <luca.boccassi@gmail.com> Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 2E03C4C99 for <dev@dpdk.org>; Thu, 7 Mar 2019 13:09:47 +0100 (CET) Received: by mail-wr1-f68.google.com with SMTP id w17so17128818wrn.12 for <dev@dpdk.org>; Thu, 07 Mar 2019 04:09:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=ncYpFF8fQyvWipJC/OZzNTETojaWScsgvP9zAAYDmQ4=; b=Kx5JjEyt1E/8pcwaFWzoKbHBLGWVIUrG2kDQ9Xd06gptKxEw7FKfG/6IRdIz50Fq/t dia3uo5gwR5eZGLUG7J9tUdk6C9ua8srwEpnlq2EqF9yX+PQt35xMcFPk6D6xENVTrOS NwvMmBGTqM7WfodRlVrwAI0iJ2pxiS/WaEhainKettFGIALsiqyN5h/qAPDuKLXXQS33 2fU1BmPDvwD/l67sjNSyigDR3mD1UoroM9A34UzAQOau8BMde+oK9m4h389YjJ7zIvFO h4OD8lK9b1hni4kH6NLJBtOEGwsP/pzFKJxBmwAUNF+dfmQe0CyRfR6KOFh3PoNj+n1C +1Iw== X-Gm-Message-State: APjAAAVFNT30LWhAAAkGHq0P6of/QEFJ0qnJ7RrXObUY1Up3ngNHaT4b Ea0xhXUNMxrabbMg20rqbbU= X-Google-Smtp-Source: APXvYqxLhzSfiK8pbhXyTtthtDfRgm/iV0ifOBBsqkkDCgDk/+3i3eF9P7L/ta+isp+iX3ezF7G4xw== X-Received: by 2002:a5d:6846:: with SMTP id o6mr6475389wrw.160.1551960586533; Thu, 07 Mar 2019 04:09:46 -0800 (PST) Received: from localhost ([2a01:4b00:f419:6f00:b00c:66c8:99df:336]) by smtp.gmail.com with ESMTPSA id a131sm6295009wmh.34.2019.03.07.04.09.45 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 07 Mar 2019 04:09:45 -0800 (PST) Message-ID: <caf34cf9dcdb634441926653aca2e799e4329cb8.camel@debian.org> From: Luca Boccassi <bluca@debian.org> To: Bruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org Date: Thu, 07 Mar 2019 12:09:44 +0000 In-Reply-To: <20190307115448.54041-1-bruce.richardson@intel.com> References: <20190307115448.54041-1-bruce.richardson@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC PATCH 0/4] One versionfile to rule them all... X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 07 Mar 2019 12:09:47 -0000 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: >=20 > * 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. >=20 > * 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. >=20 > * 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 >=20 > 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. >=20 > 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 >=20 > 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 --=20 Kind regards, Luca Boccassi