From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <bruce.richardson@intel.com>
Received: from mga05.intel.com (mga05.intel.com [192.55.52.43])
by dpdk.org (Postfix) with ESMTP id 1D0391B282
for <dev@dpdk.org>; Thu, 21 Dec 2017 15:13:01 +0100 (CET)
X-Amp-Result: UNKNOWN
X-Amp-Original-Verdict: FILE UNKNOWN
X-Amp-File-Uploaded: False
Received: from orsmga005.jf.intel.com ([10.7.209.41])
by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
21 Dec 2017 06:13:00 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.45,436,1508828400"; d="scan'208";a="186081668"
Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.106])
by orsmga005.jf.intel.com with SMTP; 21 Dec 2017 06:12:58 -0800
Received: by (sSMTP sendmail emulation); Thu, 21 Dec 2017 14:12:57 +0000
Date: Thu, 21 Dec 2017 14:12:57 +0000
From: Bruce Richardson <bruce.richardson@intel.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>
Message-ID: <20171221141257.GB8256@bricha3-MOBL3.ger.corp.intel.com>
References: <20171221122458.811-1-adrien.mazarguil@6wind.com>
<20171221122458.811-6-adrien.mazarguil@6wind.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20171221122458.811-6-adrien.mazarguil@6wind.com>
Organization: Intel Research and Development Ireland Ltd.
User-Agent: Mutt/1.9.1 (2017-09-22)
Subject: Re: [dpdk-dev] [PATCH v1 5/6] fix missing includes in exported
headers
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://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Dec 2017 14:13:02 -0000
On Thu, Dec 21, 2017 at 02:00:04PM +0100, Adrien Mazarguil wrote:
> Many exported headers rely on definitions found in rte_config.h without
> including it, as shown by the following command:
>
> grep -L '^#include <rte_config.h>' -- \
> $(grep -Rl \
> $(sed -n '/^#define \([^ ]\+\).*$/{s//\1/;H;};${x;s/\n//;s/\n/\\|/g;p;}' \
> build/include/rte_config.h) \
> -- build/include/)
>
> We cannot assume external applications will include rte_config.h on their
> own, neither directly nor through a -include parameter like DPDK does
> internally.
>
> This not only causes obvious compilation failures that can be reproduced
> with check-includes.sh such as:
>
> [...]/rte_memory.h:88:43: error: ‘RTE_CACHE_LINE_SIZE’ was not declared in
> this scope
> #define __rte_cache_aligned __rte_aligned(RTE_CACHE_LINE_SIZE)
> ^
>
> It also results in less visible issues, for instance rte_hash_crc.h relying
> on RTE_ARCH_X86_64's presence to provide dedicated inline functions.
>
> This patch partially reverts the commit below and adds missing include
> lines to the remaining files.
>
> Fixes: f1a7a5c5f404 ("remove include of generated config header")
> Cc: Thomas Monjalon <thomas@monjalon.net>
>
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> ---
Hi Adrien,
Just FYI, when we move to the new DPDK build system and pass the
necessary build meta-data to the application using pkg-config, this
should be a non-issue, as the pkg-config information will include the
"-include rte_config.h" parameter.
When investigating that, I also tried this approach of adding rte_config
to files explicitly but it did not work for me as expected, as there
were cases where the build was depending upon the rte_config.h always
being the first include in the file. Normally, the rte_* headers should
be last included, so putting it at the top just didn't seem right to me.
I don't remember the specifics, but it was something like using the RTE_
defines to determine which system header file to use e.g. BSD vs Linux.
However, this may be an internal DPDK-build restriction rather than one
that would affect user-apps our or examples.
So, with transitioning to meson and pkg-config, this issue becomes less
significant.
/Bruce