Re: plugin includes for MELT

[Basile STARYNKEVITCH <basile at starynkevitch dot net>]

Hello All,

A big thanks to Dave Korn, who wrote:
> On 27 February 2008 12:57, Basile STARYNKEVITCH wrote:
>
>
> > Practically, every MELT generated file has exactly one include directive:
> >    #include "run-basilys.h"
> > the gcc/run-basilys.h is in the MELT branch and of course include many
> > other files eg
>
> > So far, my thoughts about all this is:
> >
> > * some of the *.h are host- specific, but many are target- specific and
> > I have hard time to understand which files exactly are host- specific
> > and which one are target- specific
>
>   Does this matter?  Any given compiler only has one combination of target and
> host; are you hoping the plugins will be swappable between
> differently-configured compilers?

Of course not, I explained incorrectly. The plugin is heavily dependent 
on the actual cc1 program dlopen-ing it. The plugin depend on all the 
*.h used in this particular cc1 and useful for MELT.
> > * some of the *.h are generated, hence in the build tree (not in the
> > source dir from SVN)
> >
> > * disk space is cheap, but huge -I... include options are messy so I am
> > thinking of having a single *generated* directory, e.g. in the build
> > directory include/gcc-melt-plugin-$(host)--$(target) which is later
> > installed in $(DESTDIR)$(includedir)/gcc-melt-plugin-$(host)--$(target)/
> > and which contains all the relevant *.h files needed to run-basilys.h
> > (directly or indirectly included by it)
>
>   It might be easiest to just generate a single pre-preprocessed .i file from
> run-basilys.h (using -dD) as part of building the compiler, and install it to
> the libexec include dir (or a 'melt/' subdir thereof, mightn't it?

A big thanks for the suggestion! I am a little bit concerned about 
scenario like the following (this happens often on Debian/Sid)
  the system had some external library, like libc going from 2.7.0 to 
2.7.1) or libtldl, upgraded in a minor way (no API change). The library 
deep internal stuff (like the /usr/include/bits/*.h files on Debian) 
updated a bit. The gcc compiler did not change at all (same version).

I'm trying to understand how other "plugin" related effort deals with 
this. Perhaps nobody really cares, but I tend to believe that any plugin 
effort should install the right *.h files outside of the source or build 
directories, for plugins...

Of course, I do know that plugin might mean to some people (not to me) a 
stability in the GCC in the internal API level. I don't care about this yet.

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