This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Ping*3: [RFA:] java/config-lang.in: (target_libs): Just set to target-libjava target-zlib
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: tromey at redhat dot com
- Cc: hans-peter dot nilsson at axis dot com, gcc-patches at gcc dot gnu dot org, java-patches at gcc dot gnu dot org
- Date: Mon, 8 Aug 2005 18:13:56 +0200
- Subject: Re: Ping*3: [RFA:] java/config-lang.in: (target_libs): Just set to target-libjava target-zlib
Back from vacation, time to page in some GCC as allowed by other
priorities.
> From: Tom Tromey <tromey@redhat.com>
> Date: 21 Jul 2005 11:26:57 -0600
> >>>>> "Hans-Peter" == Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
> >> > <URL:http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00531.html>
> >>
> >> (Almost) two more weeks, time for another ping.
> Hans-Peter> Another week, yet another ping.
> Sorry this went unreviewed for so long.
Long enough for context to be lost or paged out, it seems. :-/
(It's usually a good idea to check the archives if there's a
reference to a an earlier, rejected patch or similar.
At least *I* had to look over things twice more.)
> I didn't really fully follow
> this sentence from your original note:
>
> I want to be able to build target-libffi and target-boehm-gc
> without the lack of target-libjava support (including in
> noconfigdirs per-target) deciding for me that I can't build
> them.
>
> ... but I guess you mean that you want to build libffi even though you
> don't want to build gcj and libgcj.
Again, "Setting target_libs only has an impact on what libraries
are pruned when the language isn't supported". Looking at
configure.in; grepping and inspect target_libs usage reveals:
configure.in:
...
case $add_this_lang in
no)
# Remove language-dependent dirs.
eval noconfigdirs='"$noconfigdirs "'\"$target_libs $lang_dirs\"
;;
*)
...
That's the only usage. (All libraries are built by default,
unless added to noconfigdirs, so that need is already covered.
DJ rejected the approach to disable a language if a target_libs
lib was in noconfigdirs; that need must be fulfilled by the
[new] target unsupported_languages setting.)
See the referred-to rejected patch thread for context:
<URL:http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00414.html>
> My understanding is that the target_libs variable in
> java/config-lang.in just controls what libraries should be built when
> the 'java' language is enabled.
No, see above. The effect of a library listed in the
target_libs of a language is only to *disable building that
library when the language isn't built*. A bit backwards
perhaps, but that's what we have. Changing the semantics and
whatnot might be a good idea (and has been tried and rejected in
one form, URL below), but as a separate step and not at this
stage.
> On that basis I think the current setting in that file is correct.
With the basis wrong, is the patch ok?
> All existing gcj ports really do require libffi (sort of anyway;
> libgcj limps along if it is disabled) and boehm-gc.
Misunderstanding here; wrong way dependency. (Having said that;
see also the patch, where I mentioned that I checked which
libraries are required; neither libffi and boehm-gc are needed;
limping is presumably ok.)
> Wouldn't a better fix be to change the top-level configury so that it
> doesn't disable the libraries you want even when libjava happens to be
> disabled? Or is this the only route to do this?
You mean to remove the only usage of target_libs (above)? If
not, what you say is simplest accomplished by heavy pruning of
target_libs, as in the patch, where the minimalist setting is
also explained. It could also be accomplished by having a new
variable or something with which to prune target_libs usage
before letting it set noconfigdirs, but that'd be overly
complicated for no use.
FIWI, the route to disable a language for a target, is now to
explicitly disable the language in the target configure.in case,
and target_libs will (as before) be disabled. See
<URL:http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00543.html>.
When suggesting alternative solutions, please include DJ; the
disable-front-end-not-library thing was his idea, I just want to
have libffi built using the existing machinery. See also
<URL:http://gcc.gnu.org/ml/gcc-patches/2005-06/msg00429.html>.
> I confess that some
> of this looks redundant to me (given the dependencies in Makefile.def)
> and that I haven't really tracked through this part of the build in a
> long, long time.
Yeah! Let's remove all target_libs settings! Seriously; when
Makefile.def can express the cannot-build-without-it-dependency
of a library on a language.
brgds, H-P