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: [RFA:] toplevel/configure.in (unsupported_languages): New macro.


> Date: Mon, 6 Jun 2005 18:26:56 -0400
> From: DJ Delorie <dj@redhat.com>

> > 	* configure.in (unsupported_languages): New macro.
> > 	<cris-*, crisv32-*, mmix-knuth-mmixware>: Set
> > 	unsupported_languages.
> > 	<lang_frag loop>: Set add_this_lang=no in the language is in
> > 	unsupported_languages.
> > 	* configure: Regenerate.
> 
> Ok,

Great!  Thanks for the review.

> but...
> 
> >    mmix-*-*)
> >      noconfigdirs="$noconfigdirs ${libgcj} gdb libgloss target-libgfortran"
> > +    unsupported_languages="$unsupported_languages f95 java"
> >      ;;
> 
> If we disable java, wouldn't that automatically disable the library
> directories too?

Yes; there's redundancy there.  For the record and proper
context, see also my earlier patch to gcc-patches regarding
pruning java/config-lang.in, in essence:
-target_libs=${libgcj_saved}
+target_libs="target-libjava target-zlib"

(This patch is best seen assuming that patch is in the tree, but
setting noconfigdirs here is still redundant.)

I'll fix that reduncancy, removing $libgcj from noconfigdirs for
MMIX, adding target-boehm-gc and target-libffi when the
java/config-lang.in patch is approved.  (Until that's reviewed,
the safe choice is to keep $libgcj.)

>  I mean, do we need to list ${libgcj} at all if java
> is in unsupported_languages?

Depends on what's in java/config-lang.in:target_libs; before or
after my patch.  Keeping ${libgcj} there is the safe choice.

>  Or are those the libraries that are
> written in C that support the java compiler itself, rather than the
> compiled java code?

Exactly.

> I'm thinking we want to set a precedent for this type of rule:
> 
> * If a target library can't be built because it requires an
>   unsupported language, or if it shouldn't be built because it's only
>   useful to an unsupported language, we use unsupported_language to
>   disable it.
> 
> * If a target library can't be built because of some other reason, but
>   the language it's written in is otherwise supported, then we use
>   noconfigdirs.

Works for me.

> But the idea is to tag the parts that are the *cause* of the
> non-support, not the *result* of the non-support, so if you want to
> fix it you know what to look at.

But, but, the cause for unsupporting e.g. java is (usually) that
target-libjava isn't ported!  For libfortran, it's (someone
said) that it requires Posix, and newlib isn't Posix (anyway, it
lacks functions libfortran requires).  Not a clear cause and
effect, as I then also don't want a language front-end with no
target library. ;-)  (Still, I get the point, I think.)

brgds, H-P


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