public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cao jin <caoj.fnst@cn.fujitsu.com>
To: Masahiro Yamada <yamada.masahiro@socionext.com>,
	Sam Ravnborg <sam@ravnborg.org>, Michal Marek <mmarek@suse.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	<linux-kbuild@vger.kernel.org>
Cc: <devicetree@vger.kernel.org>, Rob Herring <robh@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	Richard Purdie <richard.purdie@linuxfoundation.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Nicholas Piggin <npiggin@gmail.com>, <linux-doc@vger.kernel.org>,
	Markus Heiser <markus.heiser@darmarit.de>,
	<linux-kernel@vger.kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Rob Herring <robh+dt@kernel.org>,
	SeongJae Park <sj38.park@gmail.com>,
	"Yann E. MORIN" <yann.morin.1998@free.fr>
Subject: Re: [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files
Date: Sat, 19 Aug 2017 19:31:06 +0800	[thread overview]
Message-ID: <5998217A.1030305@cn.fujitsu.com> (raw)
In-Reply-To: <1503132577-24423-1-git-send-email-yamada.masahiro@socionext.com>

Hi,
  I am stuck in a similar problem recent days by chance.
  I am just curious about the purpose of introduction of these *_shipped
file, are they just for user's convenience when user doesn't install the
those tools?

-- 
Sincerely,
Cao jin

On 08/19/2017 04:49 PM, Masahiro Yamada wrote:
> In Linux build system convention, we do not run tools such as
> flex, bison, gperf during the kernel building.  Instead, manage
> generated C files in the repository with _shipped suffixes.
> They are simply shipped (copied) removing the _shipped suffixes
> during the kernel building.
> 
> Commit 7373f4f83c71 ("kbuild: add implicit rules for parser generation")
> added a mechanism to regenerate intermediate C files easily.
> The build rules are surrounded with ifdef REGENERATE_PARSERS.
> So, we need to pass REGENERATE_PARSERS=1 from the command line
> when we want to update them.
> 
> Here is one question.  Is it acceptable to use those rules all the time?
> That is, generate those C files by flex, bison, gperf during the
> kernel building.
> 
> This means, the build system depends on more external tools.
>>From the users' point of view, they will need to install
> flex, bison, gperf in order to build the kernel.
>>From the developers' point of view, the advantage is
> we do not need to version-control generated files, i.e. _shipped files
> will be deleted.
> 
> I'd like to know if this is acceptable or not.
> 
> For example, currently some files are simply shipped (copied)
> when building the kconfig program.
> 
>   $ make mrproper; make defconfig
>     HOSTCC  scripts/basic/fixdep
>     HOSTCC  scripts/kconfig/conf.o
>     SHIPPED scripts/kconfig/zconf.tab.c
>     SHIPPED scripts/kconfig/zconf.lex.c
>     SHIPPED scripts/kconfig/zconf.hash.c
>     HOSTCC  scripts/kconfig/zconf.tab.o
>     HOSTLD  scripts/kconfig/conf
>   *** Default configuration is based on 'x86_64_defconfig'
>   #
>   # configuration written to .config
>   #
> 
> With this series, they are created from *real* sources
> (*.y, *.l, *.gperf files).
> 
>   $ make mrproper; make defconfig
>     HOSTCC  scripts/basic/fixdep
>     HOSTCC  scripts/kconfig/conf.o
>     YACC    scripts/kconfig/zconf.tab.c
>     LEX     scripts/kconfig/zconf.lex.c
>     GPERF   scripts/kconfig/zconf.hash.c
>     HOSTCC  scripts/kconfig/zconf.tab.o
>     HOSTLD  scripts/kconfig/conf
>   *** Default configuration is based on 'x86_64_defconfig'
>   #
>   # configuration written to .config
>   #
> 
> Note:
> The tool versions in Documentation/process/changes.rst are just
> place-holders for now.  We need to figure out the minimal versions
> if we like to switch to this approach.
> 
> 
> 
> Masahiro Yamada (3):
>   kbuild: generate *.hash.c during build
>   kbuild: generate *.lex.c during build
>   kbuild: generate *.tab.c and *.tab.h during build
> 
>  Documentation/process/changes.rst        |   36 +
>  scripts/Makefile.lib                     |   26 +-
>  scripts/dtc/Makefile                     |    6 +-
>  scripts/dtc/dtc-lexer.lex.c_shipped      | 2259 ---------------------------
>  scripts/dtc/dtc-parser.tab.c_shipped     | 2303 ----------------------------
>  scripts/dtc/dtc-parser.tab.h_shipped     |  125 --
>  scripts/genksyms/Makefile                |    4 +-
>  scripts/genksyms/keywords.hash.c_shipped |  230 ---
>  scripts/genksyms/lex.lex.c_shipped       | 2291 ---------------------------
>  scripts/genksyms/parse.tab.c_shipped     | 2394 -----------------------------
>  scripts/genksyms/parse.tab.h_shipped     |  119 --
>  scripts/kconfig/Makefile                 |    1 +
>  scripts/kconfig/zconf.hash.c_shipped     |  297 ----
>  scripts/kconfig/zconf.lex.c_shipped      | 2473 ------------------------------
>  scripts/kconfig/zconf.tab.c_shipped      | 2471 -----------------------------
>  15 files changed, 53 insertions(+), 14982 deletions(-)
>  delete mode 100644 scripts/dtc/dtc-lexer.lex.c_shipped
>  delete mode 100644 scripts/dtc/dtc-parser.tab.c_shipped
>  delete mode 100644 scripts/dtc/dtc-parser.tab.h_shipped
>  delete mode 100644 scripts/genksyms/keywords.hash.c_shipped
>  delete mode 100644 scripts/genksyms/lex.lex.c_shipped
>  delete mode 100644 scripts/genksyms/parse.tab.c_shipped
>  delete mode 100644 scripts/genksyms/parse.tab.h_shipped
>  delete mode 100644 scripts/kconfig/zconf.hash.c_shipped
>  delete mode 100644 scripts/kconfig/zconf.lex.c_shipped
>  delete mode 100644 scripts/kconfig/zconf.tab.c_shipped
> 

  parent reply	other threads:[~2017-08-19 11:25 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-19  8:49 [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Masahiro Yamada
2017-08-19  8:49 ` [RFC PATCH 1/3] kbuild: generate *.hash.c during build Masahiro Yamada
2017-08-19  8:49 ` [RFC PATCH 2/3] kbuild: generate *.lex.c " Masahiro Yamada
2017-08-19  8:49 ` [RFC PATCH 3/3] kbuild: generate *.tab.c and *.tab.h " Masahiro Yamada
2017-08-21 17:12   ` Rob Herring
2017-08-19 11:31 ` Cao jin [this message]
2017-08-19 17:03 ` [RFC PATCH 0/3] kbuild: generate intermediate C files instead of copying _shipped files Linus Torvalds
2017-08-19 17:14   ` Linus Torvalds
2017-08-19 18:12     ` Linus Torvalds
2017-09-08  6:18     ` Masahiro Yamada
2017-09-08 17:22       ` Linus Torvalds
2017-09-08 18:01         ` Linus Torvalds
2017-09-08 18:39           ` Linus Torvalds
2017-09-08 21:38             ` Linus Torvalds
2017-09-09  6:39               ` Sam Ravnborg
2017-09-10 13:59                 ` Masahiro Yamada
2017-09-10 13:58               ` Masahiro Yamada
2017-09-10 16:27                 ` Linus Torvalds

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=5998217A.1030305@cn.fujitsu.com \
    --to=caoj.fnst@cn.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markus.heiser@darmarit.de \
    --cc=mchehab@kernel.org \
    --cc=mmarek@suse.com \
    --cc=npiggin@gmail.com \
    --cc=richard.purdie@linuxfoundation.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sj38.park@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=yamada.masahiro@socionext.com \
    --cc=yann.morin.1998@free.fr \
    /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