plugin includes for MELT

[Basile STARYNKEVITCH]

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