mbox series

[0/3] kbuild,kconfig: generate lexer/parser C files instead of copying _shipped files

Message ID 1512835350-8646-1-git-send-email-yamada.masahiro@socionext.com
Headers show
Series kbuild,kconfig: generate lexer/parser C files instead of copying _shipped files | expand

Message

Masahiro Yamada Dec. 9, 2017, 4:02 p.m. UTC
In Linux build system convention, pre-generated files are version-
controlled with a "_shipped" suffix.  During the kernel building,
they are simply shipped (copied) removing the suffix.

From users' point of view, this approach can reduce external tool
dependency for the kernel build,

From developers point of view, it is tedious to manually regenerate
such artifacts.  In fact, we see several patches to regenerate
_shipped files.  They are noise commits.

When we update a *.y or *.l file, it would be better to update the
corresponding _shipped file in the same commit, but it is painful.
If you use a different version of flex/bison, it will produce lots of
irrelevant diffs.

We could update _shipped files after adding various changes to the
real sources, but it is not very nice for a git-bisect'ability.
In case of a problem, "git bisect" would point to the commit updating
_shipped files, but the root cause would be in another commit that
has changed the corresponding .l or .y files.

Some months ago, I sent RFC patches to run flex, bison, and gperf
during the build.
https://lkml.org/lkml/2017/8/19/49

Basically Linus agreed this, but he found a problem in gperf, then
use of gperf in kernel was removed.

It took some months for me to come back.  This time, I installed various
versions of flex/bison on my machine, and tested them more carefully.

My current motivation is in Kconfig.
There are several Kconfig patches touching *.y and *.l
(and Linus suggested another improvement for Kconfig)
so I want to remove zconf.lex.c_shipped and zconf.tab.c_shipped now.
Kconfig has no problem for this switch.

dtc and genksyms will be taken care of later because
both of them are having shift/reduce conflicts now.
The ambiguous grammar in dtc has been fixed in upstream, but not
reflected to kernel yet.  We can proceed migration in sub-system base.


Masahiro Yamada (3):
  kbuild: add LEX and YACC variables
  kbuild: prepare to remove C files pre-generated by flex and bison
  kconfig: generate lexer and parser during build instead of shipping

 Documentation/process/changes.rst   |   25 +
 Makefile                            |    4 +-
 scripts/Makefile.lib                |   24 +-
 scripts/kconfig/Makefile            |    1 +
 scripts/kconfig/zconf.lex.c_shipped | 2473 -----------------------------------
 scripts/kconfig/zconf.tab.c_shipped | 2471 ----------------------------------
 6 files changed, 48 insertions(+), 4950 deletions(-)
 delete mode 100644 scripts/kconfig/zconf.lex.c_shipped
 delete mode 100644 scripts/kconfig/zconf.tab.c_shipped

-- 
2.7.4

Comments

Masahiro Yamada Dec. 14, 2017, 11:54 p.m. UTC | #1
2017-12-10 1:02 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> In Linux build system convention, pre-generated files are version-

> controlled with a "_shipped" suffix.  During the kernel building,

> they are simply shipped (copied) removing the suffix.

>

> From users' point of view, this approach can reduce external tool

> dependency for the kernel build,

>

> From developers point of view, it is tedious to manually regenerate

> such artifacts.  In fact, we see several patches to regenerate

> _shipped files.  They are noise commits.

>

> When we update a *.y or *.l file, it would be better to update the

> corresponding _shipped file in the same commit, but it is painful.

> If you use a different version of flex/bison, it will produce lots of

> irrelevant diffs.

>

> We could update _shipped files after adding various changes to the

> real sources, but it is not very nice for a git-bisect'ability.

> In case of a problem, "git bisect" would point to the commit updating

> _shipped files, but the root cause would be in another commit that

> has changed the corresponding .l or .y files.

>

> Some months ago, I sent RFC patches to run flex, bison, and gperf

> during the build.

> https://lkml.org/lkml/2017/8/19/49

>

> Basically Linus agreed this, but he found a problem in gperf, then

> use of gperf in kernel was removed.

>

> It took some months for me to come back.  This time, I installed various

> versions of flex/bison on my machine, and tested them more carefully.

>

> My current motivation is in Kconfig.

> There are several Kconfig patches touching *.y and *.l

> (and Linus suggested another improvement for Kconfig)

> so I want to remove zconf.lex.c_shipped and zconf.tab.c_shipped now.

> Kconfig has no problem for this switch.

>

> dtc and genksyms will be taken care of later because

> both of them are having shift/reduce conflicts now.

> The ambiguous grammar in dtc has been fixed in upstream, but not

> reflected to kernel yet.  We can proceed migration in sub-system base.

>

>

> Masahiro Yamada (3):

>   kbuild: add LEX and YACC variables

>   kbuild: prepare to remove C files pre-generated by flex and bison

>   kconfig: generate lexer and parser during build instead of shipping

>


I did not get any problem report from the 0-day bot.
I assume flex and bison are installed on their machines.


Fixed a typo pointed out by Randy,
then applied to linux-kbuild/kconfig.



-- 
Best Regards
Masahiro Yamada
Sam Ravnborg Dec. 15, 2017, 7:50 p.m. UTC | #2
Hi Masahiro.

> > In Linux build system convention, pre-generated files are version-

> > controlled with a "_shipped" suffix.  During the kernel building,

> > they are simply shipped (copied) removing the suffix.

> >

> > From users' point of view, this approach can reduce external tool

> > dependency for the kernel build,

> >

> > From developers point of view, it is tedious to manually regenerate

> > such artifacts.  In fact, we see several patches to regenerate

> > _shipped files.  They are noise commits.

...

Nice cleanup we should have does years ago.
When we introduced this we did this to minimize the time
it took to configure a clean kernel - as one of the reasons.
Since then the average computer has been significantly faster
so the time to run flex/bison is not an issue anymore.

	Sam