This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]