GCJ and $PREFIX/include

GCJ and $PREFIX/include

[Gerald Pfeifer]

Currently GCJ puts a lot of headers directly in $PREFIX/include:

  ffi.h
  ffi_mips.h
  fficonfig.h
  gc.h
  gc_backptr.h
  gc_cpp.h
  gc_local_alloc.h
  gc_pthread_redirects.h
  gcj/
  gnu/
  java/
  javax/
  jni.h
  jvmpi.h
  org/

Could we please put this into $PREFIX/include/java/3.3 similar to what we
do for C++ headers and also have the equivalent of --with-gxx-include-dir
for Java include files?

This seems more consistent (and cleaner) to me and would make packaging
easier in various cases.

Gerald
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCJ and $PREFIX/include

[Gabriel Dos Reis]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

[...]

| This seems more consistent (and cleaner) to me and would make packaging
| easier in various cases.

Indeed.  And I second your proposal.  If we all agree that this is a good
thing to do, then I believe it should happen before 3.3 gets out of the
door. 

-- Gaby

Re: GCJ and $PREFIX/include

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

Gerald> Currently GCJ puts a lot of headers directly in $PREFIX/include:

Gerald>   ffi.h
Gerald>   ffi_mips.h
Gerald>   fficonfig.h
Gerald>   gc.h
Gerald>   gc_backptr.h
Gerald>   gc_cpp.h
Gerald>   gc_local_alloc.h
Gerald>   gc_pthread_redirects.h

I'm not sure we should be installing these headers at all.
libffi is arguable, given that the independent libffi seems pretty
dead.

Gerald> Could we please put this into $PREFIX/include/java/3.3 similar
Gerald> to what we do for C++ headers and also have the equivalent of
Gerald> --with-gxx-include-dir for Java include files?

It is important to us that g++ is able to find the headers by
default, and that both g++ and gcc are able to find jni.h by default.

Beyond that I don't care where the headers end up.

Tom

Re: GCJ and $PREFIX/include

[Gerald Pfeifer]

On Tue, 6 May 2003, Tom Tromey wrote:
>>   ffi.h
>>   ffi_mips.h
>>   fficonfig.h
>>   gc.h
>>   gc_backptr.h
>>   gc_cpp.h
>>   gc_local_alloc.h
>>   gc_pthread_redirects.h
> I'm not sure we should be installing these headers at all. libffi is
> arguable, given that the independent libffi seems pretty dead.

So, how shall we proceed? ;-)

Are you going to disable installation of these headers?

Gerald

PS: Apparently this whole thread consists of several independent issues,
so perhaps it's best to address them independently; the change above would
be a nice first step.
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCJ and $PREFIX/include

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

Gerald> So, how shall we proceed? ;-)
Gerald> Are you going to disable installation of these headers?

Actually, I'm going on vacation very soon and so I don't have time to
look at this.  Maybe someone else can handle it.  If not, submit a
PR, I guess.

Tom

GCJ and $PREFIX/include revisited

[Gerald Pfeifer]

On Tue, 6 May 2003, Tom Tromey wrote:
>> Currently GCJ puts a lot of headers directly in $PREFIX/include:
>>
>>   ffi.h
>>   ffi_mips.h
>>   fficonfig.h
>>   gc.h
>>   gc_backptr.h
>>   gc_cpp.h
>>   gc_local_alloc.h
>>   gc_pthread_redirects.h
> I'm not sure we should be installing these headers at all.
> libffi is arguable, given that the independent libffi seems pretty
> dead.

I know that this is an old one, and indeed the situation has improved
quite a bit, but still there seems work to do:

  drwxr-xr-x   3 pfeifer  staff    512 Dec 14 04:58 c++
  -rw-r--r--   1 pfeifer  staff   9092 Dec 14 04:59 ffi.h
  drwxr-xr-x   2 pfeifer  staff    512 Dec 14 04:59 gcj
  drwxr-xr-x   7 pfeifer  staff    512 Dec 14 05:02 gnu
  drwxr-xr-x  15 pfeifer  staff    512 Dec 14 05:01 java
  drwxr-xr-x  10 pfeifer  staff    512 Dec 14 05:02 javax
  -rw-r--r--   1 pfeifer  staff   6870 Dec 14 04:59 jvmpi.h

The c++ headers are now nicely versioned, in c++/3.4/, but the java
headers still are put directly into $PREFIX.  How about doing something
like java/3.4 or gcj/3.4 in parallel to c++?

And do we really need ffi.h and jvmpi.h there?

(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.)

Gerald
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: GCJ and $PREFIX/include revisited

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:

Gerald> I know that this is an old one, and indeed the situation has
Gerald> improved quite a bit, but still there seems work to do:
Gerald> [ installed ffi, gcj headers ]

Gerald> The c++ headers are now nicely versioned, in c++/3.4/, but the java
Gerald> headers still are put directly into $PREFIX.  How about doing something
Gerald> like java/3.4 or gcj/3.4 in parallel to c++?

Gerald> (This is PR7305, and it would be really nice to fix this for
Gerald> GCC 3.4.  in fact, it is, somehow, a regression against
Gerald> earlier versions of GCC.)

I set target-milestone=3.4 for it.  (I haven't had much time for 3.4
bug fixes recently, but at least this way we won't forget it.)

We can easily install the headers wherever we like.  However, we'd
still like g++ to search the gcj headers by default.  So that
presumably means a patch to the standard include directories.

Gerald> 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.)

For ffi.h, I think the answer depends on whether we install libffi at
all.

Tom

Re: GCJ and $PREFIX/include revisited

[Gabriel Dos Reis]

Tom Tromey <tromey@redhat.com> writes:

| >>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:
| 
| Gerald> I know that this is an old one, and indeed the situation has
| Gerald> improved quite a bit, but still there seems work to do:
| Gerald> [ installed ffi, gcj headers ]
| 
| Gerald> The c++ headers are now nicely versioned, in c++/3.4/, but the java
| Gerald> headers still are put directly into $PREFIX.  How about doing something
| Gerald> like java/3.4 or gcj/3.4 in parallel to c++?
| 
| Gerald> (This is PR7305, and it would be really nice to fix this for
| Gerald> GCC 3.4.  in fact, it is, somehow, a regression against
| Gerald> earlier versions of GCC.)
| 
| I set target-milestone=3.4 for it.  (I haven't had much time for 3.4
| bug fixes recently, but at least this way we won't forget it.)
| 
| We can easily install the headers wherever we like.  However, we'd
| still like g++ to search the gcj headers by default.  So that
| presumably means a patch to the standard include directories.

I've yet to see a patch before commenting but I'm concerned that such
a modification of include directory would have negative impacts on C++
programs that do not use Java...

-- Gaby

Re: GCJ and $PREFIX/include revisited

[Tom Tromey]

>>>>> "Gabriel" == Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

Tom> We can easily install the headers wherever we like.  However, we'd
Tom> still like g++ to search the gcj headers by default.  So that
Tom> presumably means a patch to the standard include directories.

Gabriel> I've yet to see a patch before commenting but I'm concerned that such
Gabriel> a modification of include directory would have negative impacts on C++
Gabriel> programs that do not use Java...

It is already working right now.  You don't need any special argument
to compile a CNI-using C++ program.  If we moved the include files
without updating g++, that would be a change in behavior for CNI
users.

Tom

Re: GCJ and $PREFIX/include revisited

[Tom Tromey]

>>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:

Gerald> The c++ headers are now nicely versioned, in c++/3.4/, but the java
Gerald> headers still are put directly into $PREFIX.  How about doing something
Gerald> like java/3.4 or gcj/3.4 in parallel to c++?

Gerald> And do we really need ffi.h and jvmpi.h there?

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?

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.

Tom

Re: GCJ and $PREFIX/include revisited

[Gabriel Dos Reis]

Tom Tromey <tromey@redhat.com> writes:

| >>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:
| 
| Gerald> The c++ headers are now nicely versioned, in c++/3.4/, but the java
| Gerald> headers still are put directly into $PREFIX.  How about doing something
| Gerald> like java/3.4 or gcj/3.4 in parallel to c++?
| 
| Gerald> And do we really need ffi.h and jvmpi.h there?
| 
| 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?

you probably want $(includedir)/GCC-$(version)/
                                ^^^^

The reason we did not do that in the first place, is mostly
historical: The need for versioned headers was pressing in V3 land,
but at the time no other library seemed to be in the same position as
V3, so we did feel the urge to go on colonizing other library
install machinery :-) 

-- Gaby

Re: GCJ and $PREFIX/include revisited

[Gabriel Dos Reis]

Michael Koch <konqueror@gmx.de> writes:

| On Thu, Dec 18, 2003 at 06:18:39PM +0100, Gabriel Dos Reis wrote:
| > Tom Tromey <tromey@redhat.com> writes:
| > 
| > | >>>>> "Gerald" == Gerald Pfeifer <gerald@pfeifer.com> writes:
| > | 
| > | Gerald> The c++ headers are now nicely versioned, in c++/3.4/, but the java
| > | Gerald> headers still are put directly into $PREFIX.  How about doing something
| > | Gerald> like java/3.4 or gcj/3.4 in parallel to c++?
| > | 
| > | Gerald> And do we really need ffi.h and jvmpi.h there?
| > | 
| > | 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?
| > 
| > you probably want $(includedir)/GCC-$(version)/
| >                                 ^^^^
| 
| What about lowercase:
| 
| $(includedir)/gcc-$(version)/
| 
| I think thats more natural.

Whatever.  As far as as it is not confused with the driver named 'gcc'
-- which also happens to have version in its name.

I think GCC is better in the sense that it refers to the whole compiler
collection. 

-- Gaby

Re: GCJ and $PREFIX/include revisited

[Gabriel Dos Reis]

"C. Brian Jones" <cbj@gnu.org> writes:

| > | 
| > | What about lowercase:
| > | 
| > | $(includedir)/gcc-$(version)/
| > | 
| > | I think thats more natural.
| > 
| > Whatever.  As far as as it is not confused with the driver named 'gcc'
| > -- which also happens to have version in its name.
| > 
| > I think GCC is better in the sense that it refers to the whole compiler
| > collection. 
| > 
| 
| Uppercase is horrible, always.

That is your point of view.  The name of compiler collection is GCC, gcc
is a specific driver.  And directory name is not something you as a
user has to mess with, on a daily basis.  Most of the time, you don't
even care about it.  It is designed for automated tools.   

-- Gaby

Re: GCJ and $PREFIX/include revisited

[Gerald Pfeifer]

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

Re: GCJ and $PREFIX/include revisited

[Gerald Pfeifer]

On Fri, 2 Jan 2004, Gerald Pfeifer wrote:
> 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!

I just noticed we haven't made any progress on that, probably also because
Steven (incorrectly) qualified this as an enhancement and move the target
milestone to 3.5.0. :-(

(On why this is also a regression fix, see
<http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7305#c2>.)

>> 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!

We probably "just" need a volunteer who is sufficiently familiar with the
build system.

Gerald
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/