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 47063A0471 for ; Wed, 19 Jun 2019 20:35:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 917AD1D0C0; Wed, 19 Jun 2019 20:35:01 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id C029C1D0BB for ; Wed, 19 Jun 2019 20:35:00 +0200 (CEST) Received: from [107.15.85.130] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1hdfQ2-00006h-49; Wed, 19 Jun 2019 14:34:56 -0400 Date: Wed, 19 Jun 2019 14:34:43 -0400 From: Neil Horman To: Bruce Richardson Cc: dev@dpdk.org, Jerin Jacob Kollanukkaran , Thomas Monjalon Message-ID: <20190619183443.GC19712@hmswarspite.think-freely.org> References: <20190525184346.27932-1-nhorman@tuxdriver.com> <20190613142344.9188-1-nhorman@tuxdriver.com> <20190613142344.9188-3-nhorman@tuxdriver.com> <20190613144401.GA479@bricha3-MOBL.ger.corp.intel.com> <20190619103900.GA19712@hmswarspite.think-freely.org> <20190619104612.GA699@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190619104612.GA699@bricha3-MOBL.ger.corp.intel.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH v2 02/10] meson: add BUILDING_RTE_SDK 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" On Wed, Jun 19, 2019 at 11:46:12AM +0100, Bruce Richardson wrote: > On Wed, Jun 19, 2019 at 06:39:00AM -0400, Neil Horman wrote: > > On Thu, Jun 13, 2019 at 03:44:02PM +0100, Bruce Richardson wrote: > > > On Thu, Jun 13, 2019 at 10:23:36AM -0400, Neil Horman wrote: > > > > The __rte_internal macro is defined dependent on the value of the build > > > > environment variable BUILDING_RTE_SDK. This variable was set in the > > > > Makefile environment but not the meson environment, so lets reconcile > > > > the two by defining it for meson in the lib and drivers directories, but > > > > not the examples/apps directories, which should be treated as they are > > > > not part of the core DPDK library > > > > > > > > Signed-off-by: Neil Horman > > > > CC: Jerin Jacob Kollanukkaran > > > > CC: Bruce Richardson > > > > CC: Thomas Monjalon > > > > --- > > > > drivers/meson.build | 1 + > > > > lib/meson.build | 1 + > > > > 2 files changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/meson.build b/drivers/meson.build > > > > index 4c444f495..a312277d1 100644 > > > > --- a/drivers/meson.build > > > > +++ b/drivers/meson.build > > > > @@ -23,6 +23,7 @@ endif > > > > > > > > # specify -D_GNU_SOURCE unconditionally > > > > default_cflags += '-D_GNU_SOURCE' > > > > +default_cflags += '-DBUILDING_RTE_SDK' > > > > > > > > foreach class:dpdk_driver_classes > > > > drivers = [] > > > > diff --git a/lib/meson.build b/lib/meson.build > > > > index e067ce5ea..0e398d534 100644 > > > > --- a/lib/meson.build > > > > +++ b/lib/meson.build > > > > @@ -35,6 +35,7 @@ if is_windows > > > > endif > > > > > > > > default_cflags = machine_args > > > > +default_cflags += '-DBUILDING_RTE_SDK' > > > > if cc.has_argument('-Wno-format-truncation') > > > > default_cflags += '-Wno-format-truncation' > > > > endif > > > > > > While this will work, it's not something that individual components should > > > ever need to override so I think using "add_project_arguments()" function > > > is a better way to add this to the C builds. > > > > > That sounds like it makes sense to me, but reading the documentation for meson, > > I'm not sure I see the behavioral difference. Can you elaborate on how > > add_project_arguments behaves differently here? > > > The end result should be the same. The key differences are: > 1. Only ever needs to be set in one place > 2. Cannot be overridden by the individual objects in the build. > > So it's just slightly cleaner. If you prefer your existing approach, I'm ok > with that. > No, I like the aspect of item 2, though, just for clarification, do we really only need to set it at the top level? I ask because it seems that BUILDING_RTE_SDK should be set for the lib and drivers subtrees, but not the app subtree, as that tree, being the location of our example code, should be treated as non-core dpdk libraries, and so should throw an error if any code there attempts to use a dpdk internal only function. Or is there some other magic afoot in that subtree? Neil > /Bruce >