Re: Does gengtyped gt-*.h depends upon the configuration of the compiler?

[Basile Starynkevitch <basile@starynkevitch.net>]

Hello all,

On Thu, Mar 11, 2010 at 09:12:51AM +0100, Laurynas Biveinis wrote,
citing me Basile:

> > MELT only need gengtype to generate its gt-melt-runtime.h but I have no idea
> > if that file depends upon the configuration (and notably the target for
> > which GCC is built). The GTY-ed data of MELT does not depend (IMHO) upon the
> > configuration directly (in the sense that there is no #ifdef around GTY-ed
> > struct), but of course it points to data like Gimple or Tree which I imagine
> > depend upon the configuration of GCC (notably --enable-check but perhaps
> > also the target ...)
> 
> The gt-melt-runtime.h should only contain GC and PCH root information
> which shouldn't change between the configurations, so this file should
> be portable. OTOH, gtype-desc.h isn't.

I was thinking of MELT as a *plugin*, so gengtype is invoked in plugin
mode, with -P, for instance like
./build/gengtype -P gt-melt-runtime-plugin.h gtyp-input.list  \
  $MELT_PLUGIN_SOURCE/melt-runtime.h  $MELT_PLUGIN_SOURCE/melt-runtime.c

I just tried, and it seems to me that the generated code is fairly
portable, since it references existing GCC GTY-ed types by routine
names, like e.g. gt_ggc_m_9tree_node etc. So I guess that if some
field is target specific inside e.g. tree-s, the routine name won't
change.

While I do understand the requirement (and its current reason) that in
plugin mode, gengtype needs the entire build tree of the GCC for which
we are building a plugin, I also understand that distribution makers
are not happy of that requirement.

We cannot remove that heavy requirement for 4.5 (because 4.5 is in
stage 4, and because it is not easy to do). However, we might think of
enhancing gengtype for 4.6.



A possible way of doing that enhancement might perhaps be that 

1. (in ordinary non plugin mode, within a plugin-enabled GCC) gengtype
not only generates all the necessary gt*.h files, but also generate an
easy-to-parse textual representation (perhaps in JSON or XML or Lispy
syntax) of all the data it has processed (that is of all the GTY-ed
data descriptors). Let imagine that file will be
gcc-gty-data-descr.json

2. The installation procedure installs the gengtype binary and the
above mentioned gcc-gty-data-descr.json appropriately (probably under
`gcc-trunk -print-file-name=plugin`/etc/ ...)

3. The installed gengtype (which in my opinion should better be called
& invoked as gcc-gengtype) read data from the installed
gcc-gty-data-descr.json

Again, this is food for thought only. Comments are welcome! We sadly
cannot make that for gcc 4.5! So for gcc-4.5 building plugins which do
use PLUGIN_REGISTER_GGC_ROOTS is terrible for distribution makers
(like Debian); they have to *keep* the *build* tree of their GCC which
seems to be against the spirit of packaging systems in most Linux
distribution.



A tedious alternative might be e.g. for debian to figure out all the
files needed to gengtype and to package all of them (including a
normalized gtyp-input.list and all the files listed there and the
gengtype executable) in their gcc-4.5-plugin-dev package.



I am very sadly perhaps considering to store, e.g. in
contrib/generated-gt-melt-runtime-for-plugins.h the generated
gt-melt-runtime.h for MELT as plugin. Storing in a source depository a
generated file has to be done with caution, and storing a generated
file which needs to be "manually" regenerated is sad & ugly.

Since this message (a reply on gcc@gcc.gnu.org to the
http://gcc.gnu.org/ml/gcc/2010-03/msg00124.html message) could be of
interest to debian-gcc@lists.debian.org I am also BCC-ing it to them.

Regards.
-- 
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 mines, sont seulement les miennes} ***