RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

[Alan Modra]

On Mon, May 03, 2021 at 10:47:15AM -0400, Simon Marchi wrote:
> > Yes, I prefer the configure fix too.  If we state we require C99 in
> > binutils then we ought to be able to use C99..
> > 
> > Nick, does the configure.ac change also need to go in all subdirs, to
> > support people running make in say ld/ rather than running make in the
> > top build dir?
> 
> For GDB, it's not supported to run gdb/configure directly, you need to
> use the top-level configure.  Is it supported from some of the other
> projects in the repo?
> 
> I just tried with ld, it doesn't work since it depends on bfd also being
> built.  I tried with just bfd, it doesn't work (with the default
> configure options at least) because it requires zlib being built.

I wasn't talking about running configure, I was talking about running
make.  For example, you configure and make binutils as usual, then
after making a change to ld/ files, run make in the ld build dir.  I
don't tend to do that myself but I do run "make check" sometimes in a
subdir expecting to get the same results in that subdir as if "make
check" was run from the top level.

But I should have just tried it myself rather than asking.  CC, CPP
and others are inherited from the top level and appear with -std=gnu99
in the subdir Makefiles.  So it seems all the AC_PROG_CC in subdir
configure.ac can stay as they are.

> 
> So if all projects need to go through the top-level configure script
> anyway, and C99 is a baseline for all projects, then having the check
> only in the top-level makes sense to me.  Projects that have more
> specific requirements can have their own checks.  For example, sim/
> requires C11 now.  Unless the C99 check at top-level somehow does not
> play well with the C11 check in sim/?  Like if that would cause CC to be
> set to "gcc -std=gnu99 -std=gnu11" or something like that.
> 
> Simon

-- 
Alan Modra
Australia Development Lab, IBM