Re: RFC: No recursion into language subdirectories

[Zack Weinberg <zack at wolery dot cumb dot org>]

On Tue, Jun 20, 2000 at 12:00:48PM -0400, Kaveh R. Ghazi wrote:
>  > It was necessary to rearrange things in the Fortran and C++ front ends
>  > a bit.  In Fortran, the .j files are gone, except for str-*.j which
>  > are generated.  We lose the ability to autogenerate dependencies in
>  > there, but I suspect that logic was broken anyway.  In C++, new[12].cc
>  > are split into one file per library function, and libgcc.mk has been
>  > taught how to build them itself rather than call back to the master
>  > Makefile to do it.  I believe both these changes are a net win
>  > irrespective of what's done to the Makefiles, and I may pull them out
>  > and submit them separately.
> 
> Good idea splitting out independant chunks, jumbo patches are harder
> to review.  (I think you also mixed in your libbackend.a patch in
> there.  I realize this wasn't meant to be considered "as is" but its
> still harder to read even for the RFC phase.)

Yes, it was in there, and so were some other unrelated changes.  I do
need to be more careful.

>  > The biggest disadvantage is that we lose the ability to prune the
>  > warning switches in the language subdirs.
> 
> I think we'll also lose the ability to ask warn_summary for just java
> or fortran warnings.  E.g. warn_summary {-java|-f|-cp|-ch|-nosub}.  (I
> don't know if anyone besides me actually used these flags though, so
> its not a big deal.)

This ought to be fixable, e.g. by grepping for 'java/' on the warnings
line instead of the make Entering: and Leaving: lines.

I've occasionally wished there was a way to get it to consider
warnings outside the gcc directory as well - the target libs, for
instance.

>  >     449 function macro ??? must be used with arguments in traditional C
>  >     223 ANSI C forbids braced-groups within expressions
>  >     178 ANSI C forbids constructor expressions
>  >     141 ANSI C forbids conditional expr with only one void side
> 
> My suspicion is that some of the above might share a common root cause
> (e.g. in a header file.)  So it may be possible to fix many by
> tweaking a lower number of places than the above totals suggest.

Yes, I expect so too.

>  >   (The 'ANSI C forbids ...' warnings need to be looked at;
>  > that's not just the usual "works on all sufficiently Unixy platforms"
>  > issues, but use of GCC-specific extensions.)
> 
> Yup, we'll use __extension__ to zap these since we require gcc for the
> non-C parts.

Even so, I think we should avoid the use of extensions where
possible.  Consistency's good.

>  > Then there are the bugs this exposes.  Starting with the biggest: to
>  > build front ends other than C, we now must have a compiler that
>  > supports -c and -o together.  Otherwise, the non-C object files will
>  > be dropped in the top level directory, and the link won't find them.
>  > Worse, some front ends have object files with the same name as a
>  > backend module, so e.g. cp/expr.o will clobber expr.o.  
> 
> Rename cp/expr.c?  (I think before the g++ files had their own subdir
> all of them were prefixed with "cp-" to avoid name conflicts in the
> gcc dir.  But cp/cp-expr.c sounds redundant...)

I'd rather not rename things if it can be avoided, since you lose
(continuity of) the CVS history that way.

This is only a problem with really old compilers, anyway.

>  > A slightly tidier fix would
>  > include autoconf logic to find out whether the bootstrap compiler can
>  > handle it, and set OUTPUT_OPTION appropriately.
> 
> Right, there's already an autoconf test to do this.  You could
> override it for stage2 and later when we know we have gcc.  I would
> prefer if you did this.

Will add to next iteration of patch.

zw