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-...@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} ***
