Re: RFC: No recursion into language subdirectories

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Zack Weinberg <zack@wolery.cumb.org>
 > 
 > The appended patch changes the Makefiles so we never recurse into
 > language subdirectories.  It's got some issues; I'm not looking for
 > integration as is, but would appreciate comments.

Great, thanks for doing this.


 > 
 > 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.)



 > 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.)



 > That was being done by
 > adjusting CFLAGS when we recursed.  Some makes can adjust variables
 > for individual targets, but that feature is not POSIX, and has at
 > least two incompatible syntaxes either of which is a syntax error for
 > makes that don't support it.  Adding -pedantic and -Wtraditional to
 > language subdirs triples the number of warnings, with the top ten
 > being
 > 
 >     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.


 >      65 comparison between signed and unsigned
 >      61 pointer targets in assignment differ in signedness
 >      52 Use of ANSI string concatenation
 >      51 comma at end of enumerator list
 >      39 pointer targets in passing arg ??? of `???' differ in signedness
 >      17 promoted argument `???' doesn't match prototype
 > 
 > This is either a catastrophe, or no big deal, depending how you look
 > at it.

:-)

IMHO warning `noise' tends to make everyone ignore the serious ones.
We should try to reduce noise if possible.  Its a constant battle...


 >   (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.


 > 
 > We can still prune warnings for libgcc.


Good.  I think passing -pedantic to one of the target files also
caused an error.  I forget which (crtstuff.c?)  Jason ran into this
when he turned on -pedantic.



 > 
 > The subdir Makefiles are not terribly useful anymore.  They'll rebuild
 > their front end if you do a blind make in that directory, and that's
 > about it.  We may want to just eliminate them entirely.  This would
 > speed up rerunning config.status a bit, too.

IMO delete them.


 > 
 > 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...)

BTW, I think the fortran dir reuses the expr.h filename, which makes
it hard to include both gcc/expr.h and gcc/f/expr.h.



 > This is not a problem in a native build, we can add an -o $@ to the
 > .c.o suffix rule in stage2 and beyond.  In a cross build, I've put it
 > in unconditionally; I doubt anyone wants to build cross compilers with
 > a cc that doesn't handle -c with -o.

I sometimes do this for testing, but I only build the C front end in
these cases.


 > 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.


 > Next, if you try to build the C++ front end with any version of gcc
 > prior to 2.96 20000418 or so, you'll trip over a bug in cccp.c where
 > #line confuses the header-file search logic, so it won't be able to
 > find the right headers to compile parse.c.
 > 
 > But if you try to build the Fortran front end with any version of gcc
 > *after* that date, on a platform with malloc.h, you'll trip over a bug
 > in cpplib where <foo.h> and "foo.h" are not properly distinguished.  I
 > should have a patch for this by tomorrow.  You can work around it, in
 > the meantime, by applying Jakub's patch for the same bug (which is not
 > clean enough for a permanent fix, IMO) or by commenting out the block
 > in system.h that includes malloc.h.  Why are we using malloc.h anyway?
 > 
 > zw

We include malloc.h because some systems don't prototype malloc et al
anywhere else.  And its always safer to use the platform's prototype
rather than our backups in system.h since they may conflict with
something somewhere somehow.

See the following discussion for an example where we *must* get a
malloc prototype.  (BTW, I *love* the mailing list search engine,
found it on the first try. :-)

http://gcc.gnu.org/ml/gcc-patches/1998-07/msg00454.html


WRT the -c -o problems, these are okay since we require gcc for the
non-C parts of the compiler.  As long as a full bootstrap works with
older cc's, its fine.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions