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
