Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-12-18 09:02:17 +00:00
Code Issues Packages Projects Releases Wiki Activity
88901b9679
linux/tools/net/ynl/Makefile.deps

21 lines
909 B
Makefile
Raw Normal View History

tools: ynl: work around stale system headers The inability to include the uAPI headers directly in tools/ is one of the bigger annoyances of compiling user space code. Most projects trade the pain for smaller inconvenience of having to copy the headers under tools/include. In case of netlink headers I think that we can avoid both. Netlink family headers are simple and should be self-contained. We can try to twiddle the Makefile a little to force-include just the family header, and use system headers for the rest. This works fairly well. There are two warts - for some reason if we specify -include $path/family.h as a compilation flag, the #ifdef header guard does not seem to work. So we need to throw the guard in on the command line as well. Seems like GCC detects that the header is different and tries to include both. Second problem is that make wants hash sign to be escaped or not depending on the version. Sigh. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-14 00:28:00 +00:00
# SPDX-License-Identifier: GPL-2.0
# Try to include uAPI headers from the kernel uapi/ path.
# Most code under tools/ requires the respective kernel uAPI headers
# to be copied to tools/include. The duplication is annoying.
# All the family headers should be self-contained. We avoid the copying
# by selectively including just the uAPI header of the family directly
# from the kernel sources.
UAPI_PATH:=../../../../include/uapi/
tools: ynl: improve the direct-include header guard logic Przemek suggests that I shouldn't accuse GCC of witchcraft, there is a simpler explanation for why we need manual define. scripts/headers_install.sh modifies the guard, removing _UAPI. That's why including a kernel header from the tree and from /usr leads to duplicate definitions. This also solves the mystery of why I needed to include the header conditionally. I had the wrong guards for most cases but ethtool. Suggested-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20230621231719.2728928-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21 23:17:19 +00:00
# scripts/headers_install.sh strips "_UAPI" from header guards so we
# need the explicit -D matching what's in /usr, to avoid multiple definitions.
tools: ynl: work around stale system headers The inability to include the uAPI headers directly in tools/ is one of the bigger annoyances of compiling user space code. Most projects trade the pain for smaller inconvenience of having to copy the headers under tools/include. In case of netlink headers I think that we can avoid both. Netlink family headers are simple and should be self-contained. We can try to twiddle the Makefile a little to force-include just the family header, and use system headers for the rest. This works fairly well. There are two warts - for some reason if we specify -include $path/family.h as a compilation flag, the #ifdef header guard does not seem to work. So we need to throw the guard in on the command line as well. Seems like GCC detects that the header is different and tries to include both. Second problem is that make wants hash sign to be escaped or not depending on the version. Sigh. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-14 00:28:00 +00:00
tools: ynl: improve the direct-include header guard logic Przemek suggests that I shouldn't accuse GCC of witchcraft, there is a simpler explanation for why we need manual define. scripts/headers_install.sh modifies the guard, removing _UAPI. That's why including a kernel header from the tree and from /usr leads to duplicate definitions. This also solves the mystery of why I needed to include the header conditionally. I had the wrong guards for most cases but ethtool. Suggested-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20230621231719.2728928-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21 23:17:19 +00:00
get_hdr_inc=-D$(1) -include $(UAPI_PATH)/linux/$(2)
tools: ynl: work around stale system headers The inability to include the uAPI headers directly in tools/ is one of the bigger annoyances of compiling user space code. Most projects trade the pain for smaller inconvenience of having to copy the headers under tools/include. In case of netlink headers I think that we can avoid both. Netlink family headers are simple and should be self-contained. We can try to twiddle the Makefile a little to force-include just the family header, and use system headers for the rest. This works fairly well. There are two warts - for some reason if we specify -include $path/family.h as a compilation flag, the #ifdef header guard does not seem to work. So we need to throw the guard in on the command line as well. Seems like GCC detects that the header is different and tries to include both. Second problem is that make wants hash sign to be escaped or not depending on the version. Sigh. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-14 00:28:00 +00:00
tools: ynl: improve the direct-include header guard logic Przemek suggests that I shouldn't accuse GCC of witchcraft, there is a simpler explanation for why we need manual define. scripts/headers_install.sh modifies the guard, removing _UAPI. That's why including a kernel header from the tree and from /usr leads to duplicate definitions. This also solves the mystery of why I needed to include the header conditionally. I had the wrong guards for most cases but ethtool. Suggested-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20230621231719.2728928-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21 23:17:19 +00:00
CFLAGS_devlink:=$(call get_hdr_inc,_LINUX_DEVLINK_H_,devlink.h)
tools: ynl: work around stale system headers The inability to include the uAPI headers directly in tools/ is one of the bigger annoyances of compiling user space code. Most projects trade the pain for smaller inconvenience of having to copy the headers under tools/include. In case of netlink headers I think that we can avoid both. Netlink family headers are simple and should be self-contained. We can try to twiddle the Makefile a little to force-include just the family header, and use system headers for the rest. This works fairly well. There are two warts - for some reason if we specify -include $path/family.h as a compilation flag, the #ifdef header guard does not seem to work. So we need to throw the guard in on the command line as well. Seems like GCC detects that the header is different and tries to include both. Second problem is that make wants hash sign to be escaped or not depending on the version. Sigh. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2023-06-14 00:28:00 +00:00
CFLAGS_ethtool:=$(call get_hdr_inc,_LINUX_ETHTOOL_NETLINK_H_,ethtool_netlink.h)
tools: ynl: improve the direct-include header guard logic Przemek suggests that I shouldn't accuse GCC of witchcraft, there is a simpler explanation for why we need manual define. scripts/headers_install.sh modifies the guard, removing _UAPI. That's why including a kernel header from the tree and from /usr leads to duplicate definitions. This also solves the mystery of why I needed to include the header conditionally. I had the wrong guards for most cases but ethtool. Suggested-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Link: https://lore.kernel.org/r/20230621231719.2728928-1-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-06-21 23:17:19 +00:00
CFLAGS_handshake:=$(call get_hdr_inc,_LINUX_HANDSHAKE_H,handshake.h)
CFLAGS_netdev:=$(call get_hdr_inc,_LINUX_NETDEV_H,netdev.h)
Reference in New Issue Copy Permalink