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

[Gabriel Dos Reis]

Gerald 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

[Benjamin Kosnik]

Post by Gerald Pfeifer
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?

Although I'm a fan of the current C++ include install strategy, I'd not
be one to force it on other runtime libs. I do think that
$(prefix)/include/language/do_your_thing makes the most cohesive install
for the gcc project as a whole. It would be great to have some
consistency on this, but since consistency has never really been a goal
here.....

As a side note, C++ installation includes a version now to allow the
implementation more freedom (especially WRT ABI and new features.)
Perhaps this is not needed for java.

Two meta comments on the current configuration issues concerning includes:

--with-gxx-include-dir

Should have been named --with-include-install-dir. I don't think this
makes any sense now, since we have DESTDIR support. I would love to
remove it, unless somebody can tell me a compelling reason to keep it.

-enable-version-specific-runtime-libs

Since all C++ includes are versioned now, this really only changes the
install directory to the compiler directory. I don't think this is used
outside of C++, and furthermore, I think DESTDIR solves this too.

Both of these options have long resulted in subtle configure/make errors
that are very hard to test and often broken.

I'd rather see the GCC project standardize on one thing that everybody
could use, something that is named neutrally, and implemented broadly,
then all these weakly named options for single parts of the toolchain
that do ultra-specific things.

(Furthermore, as somebody requested a while back, I'd much rather the
gcc-3.3.0 version string be gcc-3.3.0 instead of gcc-3.3.)

back into hiding,
benjamin

[Joseph S. Myers]

Post by Benjamin Kosnik
Although I'm a fan of the current C++ include install strategy, I'd not
be one to force it on other runtime libs. I do think that
$(prefix)/include/language/do_your_thing makes the most cohesive install
for the gcc project as a whole. It would be great to have some
consistency on this, but since consistency has never really been a goal
here.....

Could any general consistent scheme be sure to address the issues in
other/346? I _think_ that including the version number in the directory
deals with most of the problems, provided that arch-specific files are in
arch-specific directories and the installed files don't otherwise depend
on the compiler configuration, but it would be good to be sure fix those
problems properly.

[David O'Brien]

Post by Benjamin Kosnik
Although I'm a fan of the current C++ include install strategy, I'd not
be one to force it on other runtime libs. I do think that
$(prefix)/include/language/do_your_thing makes the most cohesive install
for the gcc project as a whole. It would be great to have some
consistency on this, but since consistency has never really been a goal
here.....

The issue is that one may want to have gcc 3.1, 3.2.3, and 3.3-snapshot
installed all at the same time. With the positioning of the Java bits,
they stomp on top of each other.

Even if they installed into {prefix}/include/<gcc_ver>/, it is messier
for those of us making distributions where the files in
{prefix}/include/<gcc_ver>/ depends on the OS version. In the FreeBSD
package, I install everything possible under
{prefix}/lib/gcc-lib/<tuple>/<gcc_ver>/ and then run find to get a list
of names for the package list. Very nice and easy. And also importantly
keeps {prefix} clean when one has 100's of things installed.

I'd love to be able to do this with Java also.

Post by Benjamin Kosnik
--with-gxx-include-dir

...

Post by Benjamin Kosnik
Should have been named --with-include-install-dir. I don't think this
makes any sense now, since we have DESTDIR support. I would love to
remove it, unless somebody can tell me a compelling reason to keep it.

--with-gxx-include-dir is very important to the FreeBSD packages. I use:

TARGLIB= ${PREFIX}/lib/gcc-lib/${CONFIGURE_TARGET}/${GCC_REV}
CONFIGURE_ARGS+= --with-gxx-include-dir=${TARGLIB}/include/g++-v3

with much joy. Please do not remove it with out something that provides
the same functionality.

[Anthony Green]

Post by David O'Brien
The issue is that one may want to have gcc 3.1, 3.2.3, and 3.3-snapshot
installed all at the same time. With the positioning of the Java bits,
they stomp on top of each other.

It's not just that. Cross compilers (rightly) don't look in
$PREFIX/include, so you can't properly build CNI code with a cross g++.
We discussed this recently (see this thread:
http://gcc.gnu.org/ml/java/2003-04/msg00243.html ), and were wondering
if it would be OK to put the headers in $PREFIX/include/c++/VERSION. If
we pick some other directory, we'll need to make sure g++ knows to
search it as well.

AG

[Ralf Corsepius]

Post by Anthony Green

Post by David O'Brien
The issue is that one may want to have gcc 3.1, 3.2.3, and 3.3-snapshot
installed all at the same time. With the positioning of the Java bits,
they stomp on top of each other.

It's not just that. Cross compilers (rightly) don't look in
$PREFIX/include,

ACK, unfortunately, cross-gcc's do.

cf.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&pr=10532&database=gcc

Ralf

[Gerald Pfeifer]

Post by Anthony Green

Post by David O'Brien
The issue is that one may want to have gcc 3.1, 3.2.3, and 3.3-snapshot
installed all at the same time. With the positioning of the Java bits,
they stomp on top of each other.

It's not just that. Cross compilers (rightly) don't look in
$PREFIX/include, so you can't properly build CNI code with a cross g++.
http://gcc.gnu.org/ml/java/2003-04/msg00243.html ), and were wondering
if it would be OK to put the headers in $PREFIX/include/c++/VERSION.

This looks like a solution to the problem you are seeing for cross-
compiles _and_ it solves David's problem as well, _and_ it is cheap
in that we won't have to tweak include path. ;-)

I like it, and am definitely looking forward to the patch you mentioned!

Benjamin, do you have any objections?

Gerald

[Benjamin Kosnik]

Post by Gerald Pfeifer
Benjamin, do you have any objections?

Not really, although I'd still like to see the java includes in one place.

-benjamin

[Gerald Pfeifer]

Hi Anthony (et al),

Post by Gerald Pfeifer

Post by Anthony Green

Post by David O'Brien
The issue is that one may want to have gcc 3.1, 3.2.3, and 3.3-snapshot
installed all at the same time. With the positioning of the Java bits,
they stomp on top of each other.

It's not just that. Cross compilers (rightly) don't look in
$PREFIX/include, so you can't properly build CNI code with a cross g++.
http://gcc.gnu.org/ml/java/2003-04/msg00243.html ), and were wondering
if it would be OK to put the headers in $PREFIX/include/c++/VERSION.

This looks like a solution to the problem you are seeing for cross-
compiles _and_ it solves David's problem as well, _and_ it is cheap
in that we won't have to tweak include path. ;-)

I wonder whether there have been any news on this in the meantime?

(Benjamin didn't object to the $PREFIX/include/c++/VERSION solution, so
that indeed seems like the simplest approach.)

Gerald

[Gerald Pfeifer]

I hope I haven't missed anything, but how about the following? Is
anybody planning to implement that?

Post by Gerald Pfeifer

Post by Gerald Pfeifer

Post by Anthony Green

Post by David O'Brien
The issue is that one may want to have gcc 3.1, 3.2.3, and 3.3-snapshot
installed all at the same time. With the positioning of the Java bits,
they stomp on top of each other.

It's not just that. Cross compilers (rightly) don't look in
$PREFIX/include, so you can't properly build CNI code with a cross g++.
http://gcc.gnu.org/ml/java/2003-04/msg00243.html ), and were wondering
if it would be OK to put the headers in $PREFIX/include/c++/VERSION.

This looks like a solution to the problem you are seeing for cross-
compiles _and_ it solves David's problem as well, _and_ it is cheap
in that we won't have to tweak include path. ;-)

(Benjamin didn't object to the $PREFIX/include/c++/VERSION solution, so
that indeed seems like the simplest approach.)

Gerald

[Mohan Embar]

Post by Anthony Green
It's not just that. Cross compilers (rightly) don't look in
$PREFIX/include, so you can't properly build CNI code with a cross g++.

For whatever it's worth, this problem seems even worse with a crossed-native
gcc too and affects things like JNI in Java. Here are my post-build "cleanup"
scripts for my cross compiler (build=host, host!=target) and crossed-native compiler
(build!=host, host=target) builds. I'm sorry I didn't follow through on this enough to
report this or submit a real patch.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

export MINGW32_TARGET_NAME=i686-pc-mingw32

Cross Compiler
# Fix up directories
mv -f $XGCC_DIR/include/*.h $XGCC_DIR/$MINGW32_TARGET_NAME/include
for pkgdir in gcj gnu java javax
do
rm -Rf $XGCC_DIR/$MINGW32_TARGET_NAME/include/$pkgdir 2>/dev/null
mv $XGCC_DIR/include/$pkgdir $XGCC_DIR/$MINGW32_TARGET_NAME/include
done

Crossed-Native Compiler
mv -f $WINGCC_DIR/lib/lib* $WINGCC_DIR/$MINGW32_TARGET_NAME/lib
mv -f $WINGCC_DIR/include/*.h $WINGCC_DIR/$MINGW32_TARGET_NAME/include
for pkgdir in gcj gnu java javax
do
rm -Rf $WINGCC_DIR/$MINGW32_TARGET_NAME/include/$pkgdir 2>/dev/null
mv $WINGCC_DIR/include/$pkgdir $WINGCC_DIR/$MINGW32_TARGET_NAME/include
done

[Benjamin Kosnik]

Post by David O'Brien
The issue is that one may want to have gcc 3.1, 3.2.3, and 3.3-snapshot
installed all at the same time. With the positioning of the Java bits,
they stomp on top of each other.

Yes, of course. I think there are actually a couple of things being
requested.

1) a plea for java to install include files in one, java-specific
directory instead of throwing everything into $prefix/include. In
particular, $(prefix)/include/java was mentioned, and sounds great to
me. This would help package maintainers do separate c/c++/java packages,
and clarify to people what goes where.

2) a plea for java to version their includes.

3) a plea to have --with-gxx-include-dir work for all languages, at
which point I suggested it being renamed --with-installed-include-dir
and java adding support for it.

Post by David O'Brien
TARGLIB= ${PREFIX}/lib/gcc-lib/${CONFIGURE_TARGET}/${GCC_REV}
CONFIGURE_ARGS+= --with-gxx-include-dir=${TARGLIB}/include/g++-v3
with much joy. Please do not remove it with out something that provides
the same functionality.

As an FYI, please consider using

CONFIGURE_ARGS+= --with-gxx-include-dir=${TARGLIB}/include/c++

instead of

CONFIGURE_ARGS+= --with-gxx-include-dir=${TARGLIB}/include/g++-v3

as C++ library bug reports with "g++-v3" in the include line are almost
always representative of the v2 library and thus ignored or closed. It
would prevent confusion for the library maintainers if you would do
this one simple thing....

Did you see the parts of my message about DESTDIR? Do you realize you
can do something like:

make DESTDIR='${PREFIX}/lib/gcc-lib/${CONFIGURE_TARGET}/${GCC_REV}'

and all parts of the install (including java, from what I understand)
Will Just Work In The Correctly Specified Location? Agreed, this doesn't
do exactly what you want (which is to keep prefix/include clean, but as
you can see, we are attempting to clean it up....)

best,
benjamin

[Benjamin Kosnik]

Post by Benjamin Kosnik
make DESTDIR='${PREFIX}/lib/gcc-lib/${CONFIGURE_TARGET}/${GCC_REV}'

supposed to be

make DESTDIR='${PREFIX}/lib/gcc-lib/${CONFIGURE_TARGET}/${GCC_REV}' install

-benjamin

[Alexandre Oliva]

Post by Benjamin Kosnik
make DESTDIR='${PREFIX}/lib/gcc-lib/${CONFIGURE_TARGET}/${GCC_REV}'
and all parts of the install (including java, from what I understand)
Will Just Work In The Correctly Specified Location?

Err... And then you'll get say gcc installed in
${PREFIX}/lib/gcc-lib/${CONFIGURE_TARGET}/${GCC_REV}/${bindir}'.
Wrong way :-)

[Gerald Pfeifer]

I think there are actually a couple of things being requested.
1) a plea for java to install include files in one, java-specific
directory instead of throwing everything into $prefix/include. In
particular, $(prefix)/include/java was mentioned, and sounds great to
me. This would help package maintainers do separate c/c++/java packages,
and clarify to people what goes where.
2) a plea for java to version their includes.
3) a plea to have --with-gxx-include-dir work for all languages, at
which point I suggested it being renamed --with-installed-include-dir
and java adding support for it.

I believe this is an excellent summary of the issues raised by David,
and indeed would help packagers.

Unfortunately, it seems we are stalled?

Gerald

[Alexandre Oliva]

Post by Benjamin Kosnik
I don't think this
makes any sense now, since we have DESTDIR support.

DESTDIR is about temporarily installing in a tree such that you can
package something without interfering with whatever you have that's
already installed in the final location. You create a tarball (or
cpio, whatever) out of what makes to DESTDIR, and then extract it onto
the root filesystem. I don't see how DESTDIR can possibly be used as
a replacement for --with-gxx-include-dir.

Post by Benjamin Kosnik
-enable-version-specific-runtime-libs
Since all C++ includes are versioned now, this really only changes the
install directory to the compiler directory. I don't think this is used
outside of C++

Err... IIRC, this changes the install location of libraries as well,
from ${libdir} to somewhere inside ${tooldir}. It's not just about
headers.

Post by Benjamin Kosnik
I think DESTDIR solves this too.

I hope you agree DESTDIR has nothing to do with this now :-)

[David O'Brien]

Post by Alexandre Oliva

Post by Benjamin Kosnik
I don't think this
makes any sense now, since we have DESTDIR support.

...

Post by Alexandre Oliva

Post by Benjamin Kosnik
Since all C++ includes are versioned now, this really only changes the
install directory to the compiler directory. I don't think this is used
outside of C++

Err... IIRC, this changes the install location of libraries as well,
from ${libdir} to somewhere inside ${tooldir}. It's not just about
headers.

Oooo!! Even better. I can remove all the code moving the libs from
{prefix}/lib to ${tooldir}/.../. But using this.

Post by Alexandre Oliva

Post by Benjamin Kosnik
I think DESTDIR solves this too.

I hope you agree DESTDIR has nothing to do with this now :-)

I agree, but it sounds like I DESTDIR will almost do what I want -- I
only have to move bin/* back to {prefix}/bin manually.

[Alexandre Oliva]

Post by David O'Brien
I agree, but it sounds like I DESTDIR will almost do what I want -- I
only have to move bin/* back to {prefix}/bin manually.

And then you'll break the ability to relocate the tree.

Note that setting DESTDIR to tooldir, you'll get gcc-lib/.../include
et al in ${tooldir}${tooldir}/include. This is definitely NOT what
you want. Unless I'm missing something about your intentions on
keeping the thing sane :-) ;-)

[Benjamin Kosnik]

Post by Alexandre Oliva
I hope you agree DESTDIR has nothing to do with this now :-)

I see why the other two flags are useful, thanks.

-benjamin

[Tom Tromey]

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

[Gerald Pfeifer]

Post by Gerald Pfeifer
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.

[Tom Tromey]

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

[Gerald Pfeifer]

Post by Tom Tromey

Post by Gerald Pfeifer
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

[Tom Tromey]

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

[Gabriel Dos Reis]

Tom Tromey <***@redhat.com> writes:

| >>>>> "Gerald" == Gerald Pfeifer <***@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

[Tom Tromey]

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

[Tom Tromey]

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

[Gabriel Dos Reis]

Tom Tromey <***@redhat.com> writes:

| >>>>> "Gerald" == Gerald Pfeifer <***@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

[Michael Koch]

Post by Gabriel Dos Reis
|
| 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.



Michael

[Gabriel Dos Reis]

Michael Koch <***@gmx.de> writes:

| On Thu, Dec 18, 2003 at 06:18:39PM +0100, Gabriel Dos Reis wrote:
| > Tom Tromey <***@redhat.com> writes:
| >
| > | >>>>> "Gerald" == Gerald Pfeifer <***@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

[C. Brian Jones]

Post by Gabriel Dos Reis
|
|
| $(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.

Brian

[Gabriel Dos Reis]

"C. Brian Jones" <***@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

[Gerald Pfeifer]

Post by Tom Tromey

Post by Gerald Pfeifer
(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!

Post by Tom Tromey

Post by Gerald Pfeifer
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.)
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!

Post by Tom Tromey
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

[Gerald Pfeifer]

Post by Gerald Pfeifer

Post by Tom Tromey

Post by Gerald Pfeifer
(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>.)

Post by Gerald Pfeifer

Post by Tom Tromey
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