On Tue, Sep 7, 2021 at 1:02 AM Alexey Dobriyan [off-list ref] wrote:
On Mon, Sep 06, 2021 at 08:54:13AM +0200, Florian Weimer wrote:
quoted
* Linus Torvalds:
quoted
On Sat, Sep 4, 2021 at 8:19 AM Florian Weimer [off-list ref] wrote:
quoted
In any case, it would be nice to know what the real motivation is.
I don't know about the original motivation, but the reason I like that
patch after-the-fact is that I've actually been in situations where I
test out self-built compilers without installing them.
Does this really simplify matters? Why wouldn't the gcc compiler driver
find cc1, but not be able to pass the right path options, so that the
include/ subdirectory can be located as well?
quoted
Then it's convenient to have a completely standalone kernel tree.
The final patch in the series is here:
isystem: delete global -isystem compile option
<https://lore.kernel.org/linux-kernel/YQhY40teUJcTc5H4@localhost.localdomain/ (local)>
It's still not self-contained.
What do you mean?
Mainline has 1/3 and 2/3 now:
c0891ac15f0428ffa81b2e818d416bdf3cb74ab6 isystem: ship and use stdarg.h
39f75da7bcc829ddc4d40bb60d0e95520de7898b isystem: trim/fixup stdarg.h and other headers
3/3 is stuck in -next:
https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/log/?h=for-next
I'm not sure why. If the patch is bad it should be dropped from -next
as well. If it is good, it should be in mainline, otherwise more
compile time failures will happen.
See
https://lore.kernel.org/all/20210906084947.4f65761d@canb.auug.org.au/ (local)
Your 3/3 correctly detected a new use of <stddef.h>
in the drm tree.
Stephen Rothwell pointed it out a long time ago,
and fixed it in linux-next.
But, the drm maintainers did not fix it in time.
I could not fix it either since the bad commit,
b97060a99b01b4, was not in my tree.
Now it is mainlined, so my plan is to
do s/<stddef.h>/<linux/stddef.h>/
in my tree, then include your 3/3
in my second pull request in this MW.
--
Best Regards
Masahiro Yamada