Re: gengtype improvements for plugins, completed! patch 6/N [wstate]

[Basile Starynkevitch <basile at starynkevitch dot net>]

On Mon, 13 Sep 2010 10:38:17 +0300
Laurynas Biveinis <laurynas.biveinis@gmail.com> wrote:

> Below are some comments but I did not read the patch very thoroughly.
> 
> Does the state dump output completely subsume the gengtype debugging
> output? If yes, then it's a good idea to drop the latter.

I am not sure to understand the question.

The gtype.state file is generated once by gengtype -w to be latter
re-read by gengtype -r. This is the core major functionality of this
patch serie, which does not make sense without it. It is needed for
plugins to be able to run gengtype without requiring them to have GCC
source & build trees.

The -D option for debug output triggers the do_debug flag and justs
prints at various places the value of some significant variables.  It
is only here to help debugging gengtype itself, and possibly to help
gengtype hackers undertstand how gengtype actually work. It is
outputting something to help understanding the trace of gengtype. Each
DBGPRINTF message is also outputting its source location [the
gengtype.c __FILE__ name and the current __LINE__] for convenience.
I hope this option (desactivated wihtout ENABLE_CHECKING) will stay,
since understanding gengtype is so difficult.

The -d option for debug dump triggers the do_dump flag that you
introduced previously, and I did not change much about it. However, I
am now calling your dump_everything() function at several places. It
can be used by gengtype users to understand and debug the internal
gengtype data.

What do you want to drop and why?

[...]

> 
> +/* Our token lexer is heavily inspired by MELT's lexer, and share some
> +   code with the file gcc/melt-runtime.c of the GCC MELT branch!  We
> +   really want the gengtype state to be easily parsable by MELT. */
> +static struct state_token_st *
> +read_a_state_token (void)
> 
> Can you break up this function to several smaller ones?

Why?  It is a fairly standard lexer.  What is the interest of breaking
it? I cannot see the benefit of breaking it into pieces.  It seems to
me that understanding that function is as straightforward as
understanding any other lexing function with similar lexical
conventions. IIRC, guile has some similar practices.

> 
> Gengtype currently is a build tool. Gengtype after your patches will
> be both build (to build GCC itself and to produce state dump for later
> usage) and plugin-build (to read the state dump for building a
> plugin). Now build and plugin-build are not necessarily the same, in
> fact as I see it, it needs not to be any of build, host, target system
> of a GCC build!

The main functionality of gengtype for plugins developpers is of course
the ability to generate the plugin's gt-*.h files needed by
yourplugin.h yourplugin1.c yourplugin2.c

> 
> I guess in practice you will have to limit gengtype to either build or
> host of a GCC build and that would determine how it gets installed
> (but we don't install build tools, do we?).

I don't know if we have a clear host vs build machines distinction for
plugins...


Thanks for your comments.

Cheers.


-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***