From: Dmitry Golovin <dima@golovin.in>
To: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Ethan Sommer <e5ten.arch@gmail.com>,
Michal Marek <michal.lkml@markovi.net>,
Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
Sedat Dilek <sedat.dilek@gmail.com>,
Nathan Chancellor <natechancellor@gmail.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
DTML <devicetree@vger.kernel.org>
Subject: Re: [PATCH v2] kbuild: support byacc as alternative YACC to bison
Date: Mon, 11 Nov 2019 20:37:25 +0200 [thread overview]
Message-ID: <17102241573497445@vla1-b2d94eaf2344.qloud-c.yandex.net> (raw)
> Hmm, this is unfortunate since there is no common way to
> specify the header path directly.
>
> I am not sure how much effort we should invent
> to support non-GNU implementation
> since we already rely on various GNU tools.
>
> If we decide to support byacc,
> we must carry the restriction
> that bans GNU-extension.
In fact Linux now can be built without using GNU
binutils and using LLVM tools instead. It's just
one architecture and a specific config now, but
eventually the others will be built too. You can
follow the progress here:
https://github.com/ClangBuiltLinux/continuous-integration/issues/73
I believe that compatibility with different
alternative tools is a good thing as long as it
doesn't add unwanted complexity. And as this patch
is just changing command-line flags to their
portable variants and explicitly adds a couple of
definitions that are presumed by GNU bison, I
can't see a problem with it.
Regards,
Dmitry
next reply other threads:[~2019-11-11 18:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-11 18:37 Dmitry Golovin [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-10-29 1:56 [PATCH] kbuild: support byacc as alternative YACC to bison Masahiro Yamada
2019-10-29 15:01 ` [PATCH v2] " Ethan Sommer
2019-10-29 15:58 ` Frank Rowand
2019-10-30 2:58 ` Masahiro Yamada
2019-11-03 20:30 ` Ethan Sommer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17102241573497445@vla1-b2d94eaf2344.qloud-c.yandex.net \
--to=dima@golovin.in \
--cc=devicetree@vger.kernel.org \
--cc=e5ten.arch@gmail.com \
--cc=frowand.list@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.lkml@markovi.net \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=robh+dt@kernel.org \
--cc=sedat.dilek@gmail.com \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).