This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: plugin includes for MELT

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.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]