| Message ID | 20171013180243.25849-1-dianders@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
2017-10-14 3:02 GMT+09:00 Douglas Anderson <dianders@chromium.org>: > Right now there is a way to add some CFLAGS that affect target builds, > but no way to add CFLAGS that affect host builds. Let's add a way. > We'll document two environment variables: CFLAGS_HOST and > CXXFLAGS_HOST. > > We'll document that these variables get appended to by the kernel to > make the final CFLAGS. That means that, though the environment can > specify some flags, if there is a conflict the kernel can override and > win. This works differently than KCFLAGS which is appended (and thus > can override) the kernel specified CFLAGS. > > Why would I make KCFLAGS and CFLAGS_HOST work differently in this way? > My argument is that it's about expected usage. Typically the build > system invoking the kernel has some idea about some basic CFLAGS that > it wants to use to build things for the host and things for the > target. In general the build system would expect that its flags can > be overridden if necessary (perhaps we need to turn off a warning when > compiling a certain file, for instance). So, all other things being > equal, the way I'm making CFLAGS_HOST is the way I'd expect things to > work. > > So, if it's expected that the build system can pass in a base set of > flags, why didn't we make KCFLAGS work that way? The short answer is: > when building for the target the kernel is just "special". The build > system's "target" CFLAGS are likely intended for userspace programs > and likely make very little sense to use as a basis. This was talked > about in the seminal commit 69ee0b352242 ("kbuild: do not pick up > CFLAGS from the environment"). Basically: if the build system REALLY > knows what it's doing then it can pass in flags that the kernel will > use, but otherwise it should butt out. Presumably this build system > that really knows what it's doing knows better than the kernel so > KCFLAGS comes after the kernel's normal flags. > > One last note: I chose to add new variables rather than just having > the build system try to pass HOSTCFLAGS in somehow (either through the > environment or the command line) to avoid weird interactions with > recursive invocations of make. > > Signed-off-by: Douglas Anderson <dianders@chromium.org> > --- I'd like to know for-instance cases where this is useful.
Hi, On Wed, Oct 18, 2017 at 9:45 AM, Masahiro Yamada <yamada.masahiro@socionext.com> wrote: > 2017-10-14 3:02 GMT+09:00 Douglas Anderson <dianders@chromium.org>: >> Right now there is a way to add some CFLAGS that affect target builds, >> but no way to add CFLAGS that affect host builds. Let's add a way. >> We'll document two environment variables: CFLAGS_HOST and >> CXXFLAGS_HOST. >> >> We'll document that these variables get appended to by the kernel to >> make the final CFLAGS. That means that, though the environment can >> specify some flags, if there is a conflict the kernel can override and >> win. This works differently than KCFLAGS which is appended (and thus >> can override) the kernel specified CFLAGS. >> >> Why would I make KCFLAGS and CFLAGS_HOST work differently in this way? >> My argument is that it's about expected usage. Typically the build >> system invoking the kernel has some idea about some basic CFLAGS that >> it wants to use to build things for the host and things for the >> target. In general the build system would expect that its flags can >> be overridden if necessary (perhaps we need to turn off a warning when >> compiling a certain file, for instance). So, all other things being >> equal, the way I'm making CFLAGS_HOST is the way I'd expect things to >> work. >> >> So, if it's expected that the build system can pass in a base set of >> flags, why didn't we make KCFLAGS work that way? The short answer is: >> when building for the target the kernel is just "special". The build >> system's "target" CFLAGS are likely intended for userspace programs >> and likely make very little sense to use as a basis. This was talked >> about in the seminal commit 69ee0b352242 ("kbuild: do not pick up >> CFLAGS from the environment"). Basically: if the build system REALLY >> knows what it's doing then it can pass in flags that the kernel will >> use, but otherwise it should butt out. Presumably this build system >> that really knows what it's doing knows better than the kernel so >> KCFLAGS comes after the kernel's normal flags. >> >> One last note: I chose to add new variables rather than just having >> the build system try to pass HOSTCFLAGS in somehow (either through the >> environment or the command line) to avoid weird interactions with >> recursive invocations of make. >> >> Signed-off-by: Douglas Anderson <dianders@chromium.org> >> --- > > I'd like to know for-instance cases where this is useful. I'm not sure I have any exact use cases. I know vapier@ (CCed) was pushing for making sure that these flags get passed from the portage ebuild into the kernel build, so maybe he has some cases? Right now we have the "-pipe" flag that ought to be passed in to the host compiler but we're dropping it on the floor, but that doesn't seem terribly critical. ...but in general the Linux kernel doesn't have all the details about the host system. That means it can't necessarily build the tools quite as optimally (it can't pass "-mtune, right?). I could also imagine that there could be ABI flags that need to be specified? Like if we had floating point math in a host tool it would be important that the build system could tell the kernel what to use for "-mfloat-abi". ...so basically: it's all theoretical at this point in time from my point of view, but I can definitely understand how it could be necessary in the right environment. -Doug -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Douglous 2017-10-20 14:06 GMT+09:00 Doug Anderson <dianders@chromium.org>: > Hi, > > On Wed, Oct 18, 2017 at 9:45 AM, Masahiro Yamada > <yamada.masahiro@socionext.com> wrote: >> 2017-10-14 3:02 GMT+09:00 Douglas Anderson <dianders@chromium.org>: >>> Right now there is a way to add some CFLAGS that affect target builds, >>> but no way to add CFLAGS that affect host builds. Let's add a way. >>> We'll document two environment variables: CFLAGS_HOST and >>> CXXFLAGS_HOST. >>> >>> We'll document that these variables get appended to by the kernel to >>> make the final CFLAGS. That means that, though the environment can >>> specify some flags, if there is a conflict the kernel can override and >>> win. This works differently than KCFLAGS which is appended (and thus >>> can override) the kernel specified CFLAGS. >>> >>> Why would I make KCFLAGS and CFLAGS_HOST work differently in this way? >>> My argument is that it's about expected usage. Typically the build >>> system invoking the kernel has some idea about some basic CFLAGS that >>> it wants to use to build things for the host and things for the >>> target. In general the build system would expect that its flags can >>> be overridden if necessary (perhaps we need to turn off a warning when >>> compiling a certain file, for instance). So, all other things being >>> equal, the way I'm making CFLAGS_HOST is the way I'd expect things to >>> work. >>> >>> So, if it's expected that the build system can pass in a base set of >>> flags, why didn't we make KCFLAGS work that way? The short answer is: >>> when building for the target the kernel is just "special". The build >>> system's "target" CFLAGS are likely intended for userspace programs >>> and likely make very little sense to use as a basis. This was talked >>> about in the seminal commit 69ee0b352242 ("kbuild: do not pick up >>> CFLAGS from the environment"). Basically: if the build system REALLY >>> knows what it's doing then it can pass in flags that the kernel will >>> use, but otherwise it should butt out. Presumably this build system >>> that really knows what it's doing knows better than the kernel so >>> KCFLAGS comes after the kernel's normal flags. >>> >>> One last note: I chose to add new variables rather than just having >>> the build system try to pass HOSTCFLAGS in somehow (either through the >>> environment or the command line) to avoid weird interactions with >>> recursive invocations of make. >>> >>> Signed-off-by: Douglas Anderson <dianders@chromium.org> >>> --- >> >> I'd like to know for-instance cases where this is useful. > > I'm not sure I have any exact use cases. I know vapier@ (CCed) was > pushing for making sure that these flags get passed from the portage > ebuild into the kernel build, so maybe he has some cases? Right now > we have the "-pipe" flag that ought to be passed in to the host > compiler but we're dropping it on the floor, but that doesn't seem > terribly critical. > > ...but in general the Linux kernel doesn't have all the details about > the host system. That means it can't necessarily build the tools > quite as optimally (it can't pass "-mtune, right?). I could also > imagine that there could be ABI flags that need to be specified? Like > if we had floating point math in a host tool it would be important > that the build system could tell the kernel what to use for > "-mfloat-abi". > > ...so basically: it's all theoretical at this point in time from my > point of view, but I can definitely understand how it could be > necessary in the right environment. I get your point. My concern is kbuild already supports various *FLAGS. The reason for the missing optional host flags is probably people have less interest in host-tool optimization. Once we support a new FLAGS, it is hard to change/remove it. I will wait more in case other people may want to say something to this.
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index ac2363ea05c5..70bf51c1b77d 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -54,6 +54,18 @@ LDFLAGS_vmlinux -------------------------------------------------- Additional options passed to final link of vmlinux. +CFLAGS_HOST +----------- +A base set of flags to pass when compiling C files for the host (not +the target). The kernel will append some of its own flags to this +set when actually calling the compiler. + +CXXFLAGS_HOST +------------- +A base set of flags to pass when compiling C++ files for the host (not +the target). The kernel will append some of its own flags to this +set when actually calling the compiler. + KBUILD_VERBOSE -------------------------------------------------- Set the kbuild verbosity. Can be assigned same values as "V=...". diff --git a/Makefile b/Makefile index 04c4191952e0..b5e9895b2a7f 100644 --- a/Makefile +++ b/Makefile @@ -359,9 +359,10 @@ HOST_LFS_LIBS := $(shell getconf LFS_LIBS) HOSTCC = gcc HOSTCXX = g++ -HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ +HOSTCFLAGS := $(CFLAGS_HOST) \ + -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \ -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) -HOSTCXXFLAGS := -O2 $(HOST_LFS_CFLAGS) +HOSTCXXFLAGS := $(CXXFLAGS_HOST) -O2 $(HOST_LFS_CFLAGS) HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) HOST_LOADLIBES := $(HOST_LFS_LIBS)
Right now there is a way to add some CFLAGS that affect target builds, but no way to add CFLAGS that affect host builds. Let's add a way. We'll document two environment variables: CFLAGS_HOST and CXXFLAGS_HOST. We'll document that these variables get appended to by the kernel to make the final CFLAGS. That means that, though the environment can specify some flags, if there is a conflict the kernel can override and win. This works differently than KCFLAGS which is appended (and thus can override) the kernel specified CFLAGS. Why would I make KCFLAGS and CFLAGS_HOST work differently in this way? My argument is that it's about expected usage. Typically the build system invoking the kernel has some idea about some basic CFLAGS that it wants to use to build things for the host and things for the target. In general the build system would expect that its flags can be overridden if necessary (perhaps we need to turn off a warning when compiling a certain file, for instance). So, all other things being equal, the way I'm making CFLAGS_HOST is the way I'd expect things to work. So, if it's expected that the build system can pass in a base set of flags, why didn't we make KCFLAGS work that way? The short answer is: when building for the target the kernel is just "special". The build system's "target" CFLAGS are likely intended for userspace programs and likely make very little sense to use as a basis. This was talked about in the seminal commit 69ee0b352242 ("kbuild: do not pick up CFLAGS from the environment"). Basically: if the build system REALLY knows what it's doing then it can pass in flags that the kernel will use, but otherwise it should butt out. Presumably this build system that really knows what it's doing knows better than the kernel so KCFLAGS comes after the kernel's normal flags. One last note: I chose to add new variables rather than just having the build system try to pass HOSTCFLAGS in somehow (either through the environment or the command line) to avoid weird interactions with recursive invocations of make. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- Documentation/kbuild/kbuild.txt | 12 ++++++++++++ Makefile | 5 +++-- 2 files changed, 15 insertions(+), 2 deletions(-)