No new 4th PATCH yet (was: Re: 3rd PATCH to pre-select languages to be built)

[Manfred Hollstein <manfred at s-direktnet dot de>]

On Mon, 26 October 1998, 15:17:36, law@cygnus.com wrote:

 > 
 >   In message <rzqbtmzkx1i.fsf@djlvig.dl.ac.uk>you write:
 >   > >>>>> "MH" == Manfred Hollstein <manfred@s-direktnet.de> writes:
 >   > 
 >   >  MH> # This will be set by configure to "enabled" if the compiler for
 >   >  MH> # this particular language has been built, or to "disabled" if not.
 >   >  MH> LANG_ENABLED = @lang_enabled@
 >   > 
 >   > Why can't the default makefile target just test dynamically whether
 >   > the relevant compiler is there, if that's the criterion?  I.e. why
 >   > should it be configured in?
 > That seems like the natural way to do it to me too.  I guess it doesn't work
 > well if you wanted to do a LANGUAGES="c c++" in an already built tree due
 > to time constraints, but that doesn't really seem like a good reason not to
 > use the existance of the compiler as the trigger for whether or not to build
 > the runtime libraries.

I'm somewhat confused.  When I posted my 1st patch, everybody
complained to use a new argument to configure and let the configure
script enable/disable the appropriate stuff in the Makefiles. The
2nd patch was actually only a small correction of the 1st one.
The 3rd one then tried to simply avoid doing stuff for languages
whose compilers weren't configured/built.

Now, you sound to me like ``let $(LANGUAGES) decide, what to
build, and then let the language's runtime libdirs Makefiles
decide at build-time, if anything at all ought to be done''.
Is that right?

I'm asking, because I have a patch waiting in my outgoing queue, which
considers the comments I received after I sent the 3rd patch.  So,
what do we want to do now:

  1. Let the various configure{,.in} scripts munge the generated
     Makefiles to provide proper targets for the actually built
     compilers.

or

  2. Continue using $(LANGUAGES) (as we used to in the last years!),
     and fix the various Makefile.in's in the language's runtime
     libdirs to not do anything if the particular compiler isn't
     available.

???

>From looking at the size of my current patch (which does 1.), I must
say, 2. seems to be "easier to be implemented and maintained" and
has the big advantage of "letting the users build their stuff as they
used to in the past".

I will not send a new patch, until we get a final agreement on this
issue.

Thanks.

manfred