This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCJ and $PREFIX/include revisited
- From: Gerald Pfeifer <pfeifer at dbai dot tuwien dot ac dot at>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: java at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Fri, 2 Jan 2004 15:07:30 +0100 (CET)
- Subject: Re: GCJ and $PREFIX/include revisited
- References: <Pine.BSF.4.53.0305041319370.41531@acrux.dbai.tuwien.ac.at><87llxjki7o.fsf@fleche.redhat.com> <Pine.BSF.4.58.0312142309250.76198@acrux.dbai.tuwien.ac.at><87hdzynkcx.fsf@fleche.redhat.com>
On Mon, 15 Dec 2003, Tom Tromey wrote:
>> (This is PR7305, and it would be really nice to fix this for GCC 3.4.
>> in fact, it is, somehow, a regression against earlier versions of GCC.)
> I set target-milestone=3.4 for it.
Thanks!
>> And do we really need ffi.h and jvmpi.h there?
> jvmpi.h should go somewhere, I suppose. (Our JVMPI support has always
> been incomplete -- I've long wanted to disable it by default.)
On Thu, 18 Dec 2003, Tom Tromey wrote:
> While talking with a couple folks about this on irc, I realized I
> don't understand why we don't change the layout a bit to get versioned
> headers for everything all at once.
>
> I.e., instead of $(includedir)/c++/$(version), $(includedir)/gcj/$(version),
> etc, why not make $(includedir)/$(version)/ as the base, and then
> install headers directly under that?
I think that would be really helpful and make things more maintainable
and logical!
> There's a couple benefits to this. One is that we don't need to add a
> new built-in -I option when we move the java heaers. Another is that
> if we ever add another target library, we'll have an understandable
> explanation of where to put its header files.
Fully agreed!
(Just, who is going to make this change?)
Gerald