This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Trunk] patch for GNU-friendly gengtype
- From: Basile Starynkevitch <basile at starynkevitch dot net>
- To: gcc-patches at gcc dot gnu dot org
- Cc: joseph at codesourcery dot com, dnovillo at google dot com, gerald at pfeifer dot com, laurynas dot biveinis at gmail dot com
- Date: Sat, 19 Jun 2010 14:33:51 +0200
- Subject: Re: [Trunk] patch for GNU-friendly gengtype
- References: <20100616131134.GA5966@hector.lesours>
- Reply-to: basile at starynkevitch dot net
Hello All, & Joseph, Diego, Gerald who in the past did review some of my
gengtype patches, & Laurynas who also works on gengtype.
I am respectfully pinging the patch
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01621.html
On Wed, 2010-06-16 at 15:11 +0200, Basile Starynkevitch wrote:
>
> We need to improve gengtype, in particular so that it will (later) be
> installed -eg as gcc-gengtype- and be usable in plugin mode without
> requiring the entire GCC build or source tree.
This patch is needed for further gengtype enhancement.
We need the gengtype of 4.6 to be:
1. compatible with plugins, at least as 4.5's gengtype is, but better if
possible
2. remove the dirty requirement that a plugin needing gengtype (there
are some, notably MELT http://gcc.gnu.org/wiki/MELT and possibly others)
have to access to both source & build trees of the GCC for which the
plugin is compiled. This kind of dependency is unmodular, dirty, and
breaks most Linux distributions packaging systems. We really should
remove the silly requirement
http://gcc.gnu.org/onlinedocs/gccint/Plugins.html end of page:
"Plugins needing to use gengtype require a GCC build directory for the
same version of GCC that they will be linked against."
3. since the future 4.6 gengtype will be needed to build some 4.6 GCC
plugins, I believe that it should be installed, probably as gcc-gengtype
[with possibly the program suffix that has been ./configure-d, so it
will be gcc-gengtype-4.6 when GCC 4.6 will be installed as gcc-4.6 etc
etc.].
So my plan is
a. make gengtype more GNU friendly. This is what the proposed patch
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01621.html provides. When
this patch is accepted, gengtype will be more easy to use (accepting
--help & --version ...) and a little less hard to extend (we will need
extra program arguments, and a GNU getopt_long framework will help).
b. extend gengtype to be able to
* save, during GCC build time, the entire state in some textual
format. This state should be enough to re-run later gengtype in plugin
mode without requiring any GCC build or source tree, as it does in 4.5!
This state file should also be installed.
* load & use, during plugin builds, the above saved state to be able
to generate GCC marking routines for plugin needing them (e.g. MELT)
without the silly requirement of needing both GCC build & source tree to
build a plugin.
Notice that Luarynas already added some debug dump facilities inside
gengtype which are a good starting point for this save & restore state
feature.
c. enhance the installation process to install at some suitable place
the gengtype (probably as gcc-gengtype), the saved state from b. aboce
etc.
This is why I hope that my patch
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg01621.html suitably
improved if needed, will be accepted for 4.6. As I try to explain here,
it is the first step of a gengtype improvement.
Comments to this patch [which I won't repeat here] are welcome.
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} ***