From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 12B9C1AFF8 for ; Fri, 31 Aug 2018 18:26:35 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A35F221AC2; Fri, 31 Aug 2018 12:26:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 31 Aug 2018 12:26:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=Yl354dYdcHoEs7BYVLI7+WnL6O kugJOWOgWzikb5g+U=; b=fXJG2pfjYuT/3/jlobxi8y2dEB6WmDVFOB85EE2yOu XqLTSq//0FslxPsmGhofIQsIBzdb/r+F0kQXnWHqaNSqAL0U/F3X9bm2Xay/b9vx RysjyrGGNxh4mnLtufXMntm8dge/Ca5tREcEG/apxBzMKIx4OdcMKO+4ijy3m2WE A= 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Yl354d YdcHoEs7BYVLI7+WnL6OkugJOWOgWzikb5g+U=; b=qvOjqJ0liVaiIUSxoTWbO1 QLRd1+9oaFXytOkVkLlU5haDbVvL5RsMPc0Oz9QwK3RWYJb8RuZavC0wh2m+vr+g 7y7Jh3uGy1YeCP70yxEgjBYNEt/dZ5yn0zCZjD/V6YIfnEyI7rb0tXvGo6Vsjs1m 3OJL/X4X+k7V2xYplxIOyqbTqowYMGg+26Jvo5w9RqPfdeyjfuMs6LiGwqzZwe/K BTOTiGdmmHoYKf2yzTxCvQsTTofUUvTh0EKhM3sujtOWU6C5nQUDwJVZrqYZavbU T81SQvpVGU7UpA6c2n0s4cvXxOpFiywX8HmJBZCh9eYHod7rjDjY4HqbPYbxiSQQ == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D0582E408D; Fri, 31 Aug 2018 12:26:33 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , Luca Boccassi Cc: dev@dpdk.org Date: Fri, 31 Aug 2018 18:26:32 +0200 Message-ID: <11725578.3bMXKNn1vy@xps> In-Reply-To: <20180831142418.GA3024@bricha3-MOBL.ger.corp.intel.com> References: <20180831135132.14730-1-thomas@monjalon.net> <1535724642.11823.26.camel@debian.org> <20180831142418.GA3024@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] build: get version number from header file 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: Fri, 31 Aug 2018 16:26:35 -0000 31/08/2018 16:24, Bruce Richardson: > On Fri, Aug 31, 2018 at 03:10:42PM +0100, Luca Boccassi wrote: > > On Fri, 2018-08-31 at 15:51 +0200, Thomas Monjalon wrote: > > > The header file rte_version.h should be the unique place > > > to define the version number. > > > The makefile command "showversion" makes it accessible, > > > and it is used to set the meson project version with an external > > > command. > > > > > > Signed-off-by: Thomas Monjalon > > > --- > > > > > > I don't know how to check easily the meson version number. > > > Please help in testing, thanks. > > > > > > --- > > > meson.build | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/meson.build b/meson.build > > > index 84af32ece..b9d1030e7 100644 > > > --- a/meson.build > > > +++ b/meson.build > > > @@ -2,7 +2,7 @@ > > > # Copyright(c) 2017 Intel Corporation > > > > > > project('DPDK', 'C', > > > - version: '18.11-rc0', > > > + version: run_command('make', > > > 'showversion').stdout().strip(), > > > license: 'BSD', > > > default_options: ['buildtype=release', > > > 'default_library=static'], > > > meson_version: '>= 0.41' > > > > Isn't the ultimate end goal to remove the makefiles? If so, shouldn't > > meson be independent? > > > > I would tend to agree. I also think that the rte_version.h file is the > wrong place to put the version info, it would be better specified somewhere > at the root of the tree. Therefore, I think that the toplevel makefile and > meson.build files should have the version number there and then > auto-generate the rte_version.h file based on that information. Yes There are only 2 requirements: - have the version number in a single place - keep the C macros (generated or not) Any solution satisfying those two requirements will be welcome.