Hi Linus,


Very sorry that I had not responded quickly.

When I was digging into tool version dependency,
as you pointed out, gperf is a problem (but seemed one time breakage
for gperf 3.1)
flex seemed very stable for a long time.
bison seemed a bit problem if old version is used.


But, I did not have enough time to take a closer look.
I thought I should respond after I tested more, but I has been pressed
by my daily tasks, then time passed...
Very sorry.



Today, I just noticed gperf usage got dropped from the kernel.

If CONFIG_MODVERSIONS is enabled,
I notice lots of error messages.
WARNING: EXPORT symbol "finish_open" [vmlinux] version generation
failed, symbol will not be


So, I think something was broken in scripts/genksyms/.

Of course, it was a trivial conversion, so it should not be hard to fix...

gperf is clearly written by clowns that don't understand about
compatibility issues - it would have been trivial for them to add some
kind of marker define so that you could test for this directly rather
than depend on some kind of autoconf "try to build and see if it
fails" crap.

One idea may be to process the output of "gperf -v"
and embed GPERF_VERSION into the output .c files.

But, if you are unhappy with gperf breakage this time,
we can live without gperf.

It's likely not even any slower, but who the hell knows.. Do we even
care? It's almost certainly faster if you compare to generating that
gperf code.

For scripts/kconfig/, I think we do not care at all
because we usually invoke it just once when we configure the build setting.


If we enable CONFIG_MODVERSIONS, scripts/genksyms/ is invoked
over and over again.

Sorry, I have not evaluated if
the perfect hash gives us noticeable advantage or not..



-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html