From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 2549BA0C41; Thu, 24 Jun 2021 08:54:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A443A40141; Thu, 24 Jun 2021 08:54:56 +0200 (CEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by mails.dpdk.org (Postfix) with ESMTP id 2950E4003C for ; Thu, 24 Jun 2021 08:54:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A821432005C1; Thu, 24 Jun 2021 02:54:53 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 24 Jun 2021 02:54:54 -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=fm1; bh= M+SudXRpte7MiuAgNSwgND98A9PvrG4fe+6ryqT+3JI=; b=BXXdGb5xgT7mHErh kcxdJyBV33km7tr2ng/IZks8k4JL6AO16bFHmIl/pVYcJg+CUt7s2RUipJOjFwW/ 16Yidbmf5rhOiQGmw5D24vyOlCdvhK4ceGY+Hp1lcQsoi+c3ewZTQuoTOYVXUJTX OrVjaEBBxjmqvCdlxxGgJz1Aeu6E1zwl5ZzEcwkYXBCFkkx9I54OEOYgZVbfe7YT vucduekWZvQmfMjzL6Tz4N5B1ao5hDCOAJnAxPCnLYvb6wSXFoTakEavkn9knjWr B6yKu5mJD1zy6Uyt+1H8NBjBGA8KGgdhGR270OBNkYVSUEi8p/1pZhVBQAMb4Lx6 7hAy/g== 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=fm3; bh=M+SudXRpte7MiuAgNSwgND98A9PvrG4fe+6ryqT+3 JI=; b=vFEEUtUESTW0SsEoakK62JC6QfdJyvUSi2LkB4ZhOtXmcBFUHK2+yuS0A axyM5Gu24TbDBfffe0p6BnBT5UOy9V/q11jdyNrtNbmq7B3MuTgooJbZ1dCAEjxw rhfpVhuelFtX8rSqO0BDA3RCW9fmgkcnsk5yl4tivvDilHgGkwU9m5aUycTtlnHy jkKL6D5OBsqkuED0c9fl9xJkuaqYOnP7col90FXeNabLQ5tNqq2rZWNWlwyrUZVn R4vijnwbkpFpLxh+s+vO5AYuBF1gsZZA5mYOqdLT3GPQPsW33HDqDAomAbz8g1iu Eyq15dVXjTHvas/Nvr9uL9TPavLOQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeggedguddtjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhgggfgtsehtuf ertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghs sehmohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepudeggfdvfeduffdtfe eglefghfeukefgfffhueejtdetuedtjeeuieeivdffgeehnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonh drnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Jun 2021 02:54:52 -0400 (EDT) From: Thomas Monjalon To: Tyler Retzlaff Cc: dev@dpdk.org, ferruh.yigit@intel.com, dmitry.kozliuk@gmail.com, david.marchand@redhat.com Date: Thu, 24 Jun 2021 08:54:49 +0200 Message-ID: <3277479.bKIgzLV6lZ@thomas> In-Reply-To: <20210623182657.GA24634@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20210623182657.GA24634@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [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" 23/06/2021 20:26, Tyler Retzlaff: > 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. Macros are simple so the option 1 is not that bad. > 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)) We should keep a macro in rte_common.h which triggers an explicit error if not overriden for the toolchain. That way we can have a single doxygen comment in rte_common.h like it is done in lib/eal/include/generic/ > // lib/eal/include/rte_common.h > #include The include may be done in the reverse order: the toolchain-specific .h in lib/eal/gcc/include/ includes generic/rte_common.h in lib/eal/include/generic/. If both have the same name, we keep #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.