Re: GCJ and $PREFIX/include

Re: GCJ and $PREFIX/include

[Benjamin Kosnik]

> 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

Re: GCJ and $PREFIX/include

[Joseph S. Myers]

On Sun, 4 May 2003, Benjamin Kosnik wrote:

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

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: GCJ and $PREFIX/include

[David O'Brien]

On Sun, May 04, 2003 at 01:57:29PM -0500, Benjamin Kosnik wrote:
> 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.


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

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

-- 
-- David  (obrien@FreeBSD.org)

Re: GCJ and $PREFIX/include

[Anthony Green]

On Sun, 2003-05-04 at 13:55, David O'Brien wrote:
> 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

Re: GCJ and $PREFIX/include

[Benjamin Kosnik]

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

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

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

Re: GCJ and $PREFIX/include

[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

Re: GCJ and $PREFIX/include

[Alexandre Oliva]

On May  5, 2003, Benjamin Kosnik <bkoz@redhat.com> wrote:

> 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 :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCJ and $PREFIX/include

[Alexandre Oliva]

On May  4, 2003, Benjamin Kosnik <bkoz@redhat.com> wrote:

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

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

> I think DESTDIR solves this too.

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

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCJ and $PREFIX/include

[David O'Brien]

On Mon, May 05, 2003 at 08:03:30PM -0300, Alexandre Oliva wrote:
> > I don't think this
> > makes any sense now, since we have DESTDIR support.
... 
> > 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.

> > 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.
 
-- 
-- David  (obrien@FreeBSD.org)

Re: GCJ and $PREFIX/include

[Alexandre Oliva]

On May  5, 2003, "David O'Brien" <obrien@FreeBSD.org> wrote:

> 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 :-) ;-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCJ and $PREFIX/include

[Benjamin Kosnik]

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

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

-benjamin

Re: GCJ and $PREFIX/include

[Ralf Corsepius]

Am Mon, 2003-05-05 um 04.41 schrieb Anthony Green:
> On Sun, 2003-05-04 at 13:55, David O'Brien wrote:
> > 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

Re: GCJ and $PREFIX/include

[Gerald Pfeifer]

On Mon, 4 May 2003, Anthony Green wrote:
>> 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.

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
-- 
Gerald "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCJ and $PREFIX/include

[Benjamin Kosnik]

>Benjamin, do you have any objections?

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

-benjamin

Re: GCJ and $PREFIX/include

[Gerald Pfeifer]

Hi Anthony (et al),

On Thu, 8 May 2003, Gerald Pfeifer wrote:
>>> 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.
> 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 "Jerry"   pfeifer@dbai.tuwien.ac.at   http://www.pfeifer.com/gerald/

Re: GCJ and $PREFIX/include

[Gerald Pfeifer]

On Sun, 4 May 2003, Benjamin Kosnik wrote:
> 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
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: GCJ and $PREFIX/include

[Gerald Pfeifer]

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

On Wed, 18 Jun 2003, Gerald Pfeifer wrote:
> On Thu, 8 May 2003, Gerald Pfeifer wrote:
>>>> 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.
>> 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
-- 
Gerald Pfeifer (Jerry)   gerald@pfeifer.com   http://www.pfeifer.com/gerald/

Re: GCJ and $PREFIX/include

[Mohan Embar]

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

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

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

[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

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/