Matthias Klose wrote:
[posted on both gcc@ & debian-gcc@ lists]
On 14.03.2010 13:15, Basile Starynkevitch wrote:
See also http://gcc.gnu.org/ml/gcc/2010-03/msg00129.html &
http://gcc.gnu.org/ml/gcc/2010-03/msg00132.html - for those new to MELT see
http://gcc.gnu.org/wiki/MiddleEndLispTranslator and other MELT related
pages on GCC wiki.
Basile Starynkevitch wrote in
http://lists.debian.org/debian-gcc/2010/03/msg00047.html
Now, one of the issues about MELT & Debian packaging is the fact that
melt-runtime.c (the source of melt.so plugin) uses GTY
http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information
& register GGC roots thru PLUGIN_REGISTER_GGC_ROOTS ... Hence, it
needs gengtype (from GCC 4.5 build tree) to generate gt-melt-runtime.h
[#include-ed from melt-runtime.c] so the entire GCC 4.5 source & build
trees are needed to build melt.so (or any other gengtyp-ing GCC plugin).
there was another request to add the gengtype binary to the package,
required by the dragonegg plugin. details at:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562882#13
Is the binary all, which would need to be added?
No, to run gengtype for a plugin, you need gcc/gtyp-input.list and all
the files listed inside, which means a significant part of GCC source &
build trees (you need the gengtype binary from the build tree, but you
also need several *.h header files from that build tree, and perhaps
even some generated *.c files also there).
I have no idea if that is feasible within Debian. In other words, how
badly does that hurt the usual Debian package machinery?
Actually, the gengtype for plugin is somehow a kludge. It definitely
should be improved. But within GCC, we probably don't have time to do
that before 4.5. See also my message
http://gcc.gnu.org/ml/gcc/2010-03/msg00140.html
I hope that for 4.6, gengtype will be improved (I hope to contribute a
bit on that), but for 4.5 my feeling is that gengtype is sadly frozen. I
actually don't understand the current state of GCC trunk (i.e. soon to
be released 4.5) w.r.t. plugins [including gengtype]. What does stage 4
[bug fixes only] means for the newly born plugin infrastructure inside
GCC trunk?
And for the MELT plugin, I just made a tar snapshot referenced on
http://gcc.gnu.org/wiki/MELT%20tutorial (and I intend to update that
snapshot quite often) what I do there is ugly but works: I did generate
my gt-melt-runtime.h file (which is generated by gengtype in plugin
mode) and put it in the tar ball as
melt/generated/gt-melt-runtime-plugin.h hence ordinary users wanting to
compile MELT as a plugin don't need all the gengtype & related files
(which practically means a lot of the GCC source & build trees) but
could copy the gt-melt-runtime-plugin.h as gt-melt-runtime.h (hence
avoiding the need to generate that file). Of course, this won't work if
one want to edit MELT runtime source files melt-runtime.[ch] . In
practical terms, one can build MELT plugin (and use it, and even edit
the *.melt files which are the bulk of the work) without the GCC build &
source trees, but if you want to really edit & enhance the MELT runtime,
you better work on MELT as a branch (MELT as a branch is GCC trunk +
MELT specific files; it is mostly identical to GCC trunk + MELT plugin).
For what it worth, the ""generated but provided""
gt-melt-runtime-plugin.h file ends with
a comment to help to check, perhaps in a Debian installation procedure,
that it matches the source files its depends of (i.e.
melt-runtime.[hc]). It is ending with:
/* gt-melt-runtime-plugin.h file generated Sun 14 Mar 2010 10:08:18 AM CET
682216b6c67b29e5ba8082df0bfaad5e melt-runtime.h
265573514c86a89d8b8956afe5b8058c melt-runtime.c
*/
So if packaged plainly in the melt plugin package, there is at least a
way to warn the user if he changed melt-runtime.h. I am ashamed & hate
that, it is some kind of unvoluntary "Tivo"-isation of free software (in
the sense that you cannot arbitrarily edit all files of the MELT plugin
without the MELT branch) but you definitely can edit & build MELT as a
GCC branch, and once you did build that GCC MELT branch, you can quite
easily built the melt.so GCC plugin.
I have absolutely no idea if a Debian package can be defined as
depending upon both the source and the build tree of another package
(GCC 4.5). To Debian people: is that possible at all?
BTW, how some other bootstrapped software (perhaps Chicken Scheme
compiler, Ocaml compiler, ...) are packaged under Debian? Maybe it could
give some insights?
And today's URL of MELT plugin snapshot is
http://starynkevitch.net/Basile/GCC-MELT-plugin--snapshot-rev157446-2010-march-14.tgz
but please don't remember that long URL. I will change it quite often,
and update its reference in http://gcc.gnu.org/wiki/MELT%20tutorial
Besides, MELT is still quite buggy, so I hope that if some kind Debian
developer manage to package it as a plugin (Sylvestre Ledru offered
that help; I am grateful to him, but he is on a trip this week-end) he
will upload the MELT snapshot regularly, e.g. from SubVersion of the
MELT branch (I will make the first MELT release when gcc-4.5 will be
released, and when I will have corrected a few important bugs inside).
Cheers.
--
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} ***
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b9d57b4.50...@starynkevitch.net
