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: gtyp-input.list should contain absolute paths.

On Sun, Jul 5, 2009 at 8:26 AM, Basile
> Ian Lance Taylor wrote:
>> Basile STARYNKEVITCH <> writes:
>>> ? @: $(call write_entries_to_file,$(realpath $(GTFILES)),tmp-gi.list)
>>> ? $(SHELL) $(srcdir)/../move-if-change tmp-gi.list gtyp-input.list
>>> ? $(STAMP) s-gtyp-input
>> In general, one should try to avoid changing a user specified relative
>> path to an absolute path. ?In this case, the user specification comes
>> from how they invoked configure. ?Absolute paths have different
>> behaviour in automount environments. ?It's OK to temporarily change from
>> a relative to an absolute path, but changing to an absolute path and
>> writing that to a file should be avoided when possible.
>> It's not clear to me why plugins need to deal with gtyp-input.list.
> In plugin mode ?(for the few plugins using PLUGIN_REGISTER_GGC_ROOTS),
> gengtype needs a file list. So a plugin build (in its own directory) would
> want to run (in Makefile syntax)
> $(GCCBUILD)/gcc/gengtype -p $(GCCSOURCE)/gcc
> $(GCCBUILD)/gcc/gtype-input.list plugin.c
> However, this won't work, because the gtype-input.list contains (even when
> GCC was configured with absolute paths) a few relative file paths (notably
> auto-host.h).
>> ?I
>> thought we were trying to make it possible to build plugins with a set
>> of installed header files. ?If plugins need to read gtyp-plugin.list,
>> they need access to the complete source code.
> Yes, but a Makefile for a plugin cannot even use the
> $(GCCBUILD)/gcc/gtype-input.list it should transform it to transform
> relative paths to absolute ones, and that is painful.
>> ?In that case, can't they
>> just apply the same transformations that gengtype itself applies?
> I don't understand what transformations are you referring to.
> However, there might be another solution: have the gcc/ generate
> both the current gtype-input.list and another gtype-input-absolute.list
> which contains only absolute paths, and ?document that plugins could use
> that gtype-input-absolute.list (perhaps adding a caveat about automounters).
> What do you think??

How do you think distributors should package a gcc-devel package
containing all necessary files for plugin development?

I am really curious, so maybe you can take one of the existing
packagings for GCC trunk and modify it accordingly?  (Well,
I know of one existing obviously - you can get it at


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