From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 60121C4743C for ; Wed, 23 Jun 2021 18:27:01 +0000 (UTC) Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by mail.kernel.org (Postfix) with ESMTP id D679D61164 for ; Wed, 23 Jun 2021 18:27:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D679D61164 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CB05C40141; Wed, 23 Jun 2021 20:26:59 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 491024003F for ; Wed, 23 Jun 2021 20:26:58 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 9EFA320B7188; Wed, 23 Jun 2021 11:26:57 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9EFA320B7188 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1624472817; bh=flge/tgJLGyG1M/nHlLqWmTa9odnG3OKiUTsQvHQKog=; h=Date:From:To:Cc:Subject:From; b=QFl8ru9w9nIziyvPiqzDEqyJFxF1ura3+Fb5E6b+TcqKI59GWQw3v7ZZxpW/gTtlR wGXeh2wXZb9vKEzE6x0WMwa21RfoUABje6FBv8t0BXik7PXvvgZUM3Utkf7mSU+DMI yXG0bgYDboxgj1MEK+SAk+3obxZyb3Jr4UYAA3VM= Date: Wed, 23 Jun 2021 11:26:57 -0700 From: Tyler Retzlaff To: dev@dpdk.org Cc: thomas@monjalon.net, ferruh.yigit@intel.com, dmitry.kozliuk@gmail.com, david.marchand@redhat.com Message-ID: <20210623182657.GA24634@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [dpdk-dev] [RFC] toolchain specific macro expansion X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" today rte_common.h defines common macros for use by dpdk and consuming applications. most expansions are specific to the gcc toolchain. example // lib/eal/include/rte_common.h /** * Hint never returning function */ #define __rte_noreturn __attribute__((noreturn)) there is an anticipated need rte_common.h to expose alternate expansions for non-gcc toolchains in the future and would like comments on how to achieve this in an agreeable manner. option 1 add conditional compilation directly to rte_common.h example // lib/eal/include/rte_common.h /** * Hint never returning function */ #ifdef RTE_TOOLCHAIN_GCC #define __rte_noreturn __attribute__((noreturn)) #endif #ifdef RTE_TOOLCHAIN_FOO #define __rte_noreturn __foo_expansion_for_noreturn #endif represents the simplest approach technically but may be tedious to maintain due to the number of macros and number of conditional expansions per macro. option 2 add toolchain specific files (follow existing platform/os includes pattern) example: // lib/eal/gcc/rte_toolchain_common.h #define __rte_noreturn __attribute__((noreturn)) // lib/eal/include/rte_common.h #include // meson.build (illustrative change) host_toolchain = cc.get_id() # e.g. gcc global_inc = include_directories('.', 'config', 'lib/eal/include', 'lib/eal/@0@/include'.format(host_machine.system()), 'lib/eal/@0@/include'.format(arch_subdir), 'lib/eal/@0@/include'.format(host_toolchain), ) results in the introduction of more files that need to be published/installed for applications but separate files per implementation allow for easier maintainability. we are interested in hearing about alternatives not listed here but in the absence of other options we would propose to submit a patch following option 2. comments and alternatives welcome. thanks