From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id E72391B3BA for ; Wed, 27 Mar 2019 01:34:07 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C879D32A1; Tue, 26 Mar 2019 20:34:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 26 Mar 2019 20:34:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=Uo8QzQuadyLhFRrb9lr3J1oi6ex8Pv5d4owRyGJHq6Q=; b=ZKb5ag35kqht eu8urScPA6rh7N9onpiJ87Qkji4I8Lf9WykEoA+RvQHKJMENOcwSZ74Ps+EbZiLI RR2qwPWi92pSQzZ2cipcWmrr8z5HRfhuSXYEiF4ponFqjz9nrCa/ghYwGjXTE7+y 4ynWC0KFfxquVfRPvfSO+TEp4+fWHw4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Uo8QzQuadyLhFRrb9lr3J1oi6ex8Pv5d4owRyGJHq 6Q=; b=Oef2XRMPzGFnh3TK1A3xSbTOhPWvD0dmLOT7gYSolRoNrgcXVDsCdvmPb PyUvwiFoR+MvYHVI6EHZE51z837N9Vw/aPo7L8qKjEKzrit44zczQlURu26kyltn iyHo7mM06o48Et7PzOJIV1XjsuA8mSKlx9Dg/1BYkvI/XPMHcD9ELztuHZnhKKQe DwwNVNwB+CAKfC70htKdDl2QxKy+i79CA23s3WcVFcb9wyeawgJQ3/j0SnTddmDS j2WdOqilnZAGIDO2c91dC2fafMq7hsxtVOB/ufBSw5NWhbNBlxXj/TaJLkDiC6xO mcShRzXxolPEbkeQgqZcfGhH9zcWw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedugddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepshgukhgtohhnfhhighdrmhhknecukfhppeejjedrudefgedrvddtfedrudek geenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnh gvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2EF44E40FF; Tue, 26 Mar 2019 20:34:05 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, David Marchand , Luca Boccassi Date: Wed, 27 Mar 2019 01:34:03 +0100 Message-ID: <1931548.fcoo6cO5ln@xps> In-Reply-To: <20190315182022.39976-1-bruce.richardson@intel.com> References: <20190307115448.54041-1-bruce.richardson@intel.com> <20190315182022.39976-1-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 00:34:08 -0000 15/03/2019 19:20, Bruce Richardson: > 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 > manageable 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. > > --- > V3: Reworked following review from Thomas Monjalon. Main change is to how > the RTE_VER_RELEASE value is computed for non-release candidates. > Also added int() conversion to each version value to remove leading > zeros > V2: Updated following review from David Marchand. > > Bruce Richardson (4): > build: add single source of DPDK version number > build: move meson version handling to config directory > build: use version number from config file > eal: remove unneeded version logic Applied, thanks From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id E3EB0A05D3 for ; Wed, 27 Mar 2019 01:34:09 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 45E5E1B3E0; Wed, 27 Mar 2019 01:34:09 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by dpdk.org (Postfix) with ESMTP id E72391B3BA for ; Wed, 27 Mar 2019 01:34:07 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id C879D32A1; Tue, 26 Mar 2019 20:34:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 26 Mar 2019 20:34:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=Uo8QzQuadyLhFRrb9lr3J1oi6ex8Pv5d4owRyGJHq6Q=; b=ZKb5ag35kqht eu8urScPA6rh7N9onpiJ87Qkji4I8Lf9WykEoA+RvQHKJMENOcwSZ74Ps+EbZiLI RR2qwPWi92pSQzZ2cipcWmrr8z5HRfhuSXYEiF4ponFqjz9nrCa/ghYwGjXTE7+y 4ynWC0KFfxquVfRPvfSO+TEp4+fWHw4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Uo8QzQuadyLhFRrb9lr3J1oi6ex8Pv5d4owRyGJHq 6Q=; b=Oef2XRMPzGFnh3TK1A3xSbTOhPWvD0dmLOT7gYSolRoNrgcXVDsCdvmPb PyUvwiFoR+MvYHVI6EHZE51z837N9Vw/aPo7L8qKjEKzrit44zczQlURu26kyltn iyHo7mM06o48Et7PzOJIV1XjsuA8mSKlx9Dg/1BYkvI/XPMHcD9ELztuHZnhKKQe DwwNVNwB+CAKfC70htKdDl2QxKy+i79CA23s3WcVFcb9wyeawgJQ3/j0SnTddmDS j2WdOqilnZAGIDO2c91dC2fafMq7hsxtVOB/ufBSw5NWhbNBlxXj/TaJLkDiC6xO mcShRzXxolPEbkeQgqZcfGhH9zcWw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedugddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepshgukhgtohhnfhhighdrmhhknecukfhppeejjedrudefgedrvddtfedrudek geenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnh gvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2EF44E40FF; Tue, 26 Mar 2019 20:34:05 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson Cc: dev@dpdk.org, David Marchand , Luca Boccassi Date: Wed, 27 Mar 2019 01:34:03 +0100 Message-ID: <1931548.fcoo6cO5ln@xps> In-Reply-To: <20190315182022.39976-1-bruce.richardson@intel.com> References: <20190307115448.54041-1-bruce.richardson@intel.com> <20190315182022.39976-1-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v3 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190327003403.Vnr04ykAgtwhA7HcfGmGPtM_hPFPHRGembp61UcVarw@z> 15/03/2019 19:20, Bruce Richardson: > 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 > manageable 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. > > --- > V3: Reworked following review from Thomas Monjalon. Main change is to how > the RTE_VER_RELEASE value is computed for non-release candidates. > Also added int() conversion to each version value to remove leading > zeros > V2: Updated following review from David Marchand. > > Bruce Richardson (4): > build: add single source of DPDK version number > build: move meson version handling to config directory > build: use version number from config file > eal: remove unneeded version logic Applied, thanks