On 2/20/21 8:46 AM, David Malcolm via Gcc wrote:
On Sat, 2021-02-20 at 15:25 +0100, David Brown wrote:
On 19/02/2021 12:18, Jonathan Wakely via Gcc wrote:
On Fri, 19 Feb 2021 at 09:42, David Brown wrote:
Just to be clear - I am not in any way suggesting that this
situation is
the fault of any gcc developers. If configure scripts are
failing
because they rely on poor C code or inappropriate use of gcc
(code that
requires a particular C standard should specify it - gcc has the
"-std="
flags for that purpose), then the maintainers of those scripts
should
fix them. If Fedora won't build just because the C compiler
insists C
code is written in C, then the Fedora folk need to fix their
build system.
It's not Fedora's build system, it's the packages in Fedora's build
systems. Lots of them. And those same packages are in every other
Linux distro, so everybody needs to fix them.
It seems to me that there are two very different uses of gcc going on
here. (I'm just throwing up some ideas here - if people think they
are
daft, wrong or impractical, feel free to throw them out again! I am
trying to think of ways to make it easier for people to see that
there
are problems with their C or C++ code, without requiring impractical
changes on large numbers of configuration files and build setups.)
gcc can be used as a development tool - it is an aid when writing
code,
and helps you write better code. Here warnings of all sorts are
useful,
as it is better to find potential or real problems as early as
possible
in the development process. Even warnings about style are important
because they improve the long-term maintainability of the code.
gcc can also be used to build existing code - for putting together
distributions, installing on your own machine, etc. Here flags such
as
"-march=native" can be useful but non-critical warnings are not,
because
the person (or program) running the compiler is not a developer of
the
code. This use is as a "system C compiler".
I think there's an important insight here, in that there's a
distinction between:
(a) the edit-compile-debug cycle where the user is actively hacking on
the code themself (perhaps a project they wrote, or someone else's),
where they just made a change to the code and want to see what
happens,
as opposed to
(b) a batch rebuild setting, where the user is recompiling a package,
and GCC is a detail that's being invoked by a hierarachy of build
systems (e.g. a Fedora mass rebuild that invokes koji, that invokes
rpmbuild, that invokes some build tool, which eventually invokes gcc);
perhaps a dependency changed, and the user is curious about what breaks
(and hoping that nothing does, since they know nothing about this
particular code, maybe they're just trying to get the distro to boot on
some new architecture).
I think we need to think about both of these use-cases e.g. as we
implement our diagnostics, and that we should mention this distinction
in our UX guidelines...
Is it possible to distinguish these uses, and then have different
default flags? Perhaps something as simple as looking at the name
used
to call the compiler - "cc" or "gcc" ?
...but I'm wary of having an actual distinction between them in the
code; it seems like a way to complicate things and lead to "weird"
build failures.
Thought experiment: what might a "--this-is-my-code" option do?
I suspect any solution that relies on the user having to do something
they don't already [know how to] do is going to be of help only to
the negligible minority of advanced (or super careful) users. Those
who would benefit from strict checking the most are typically not in
that group.
Not all build systems also make changing compiler command line options
easy or even possible.
So I wonder if changing configure to either implicitly use a command
line option for its tests or set an environment variable to request
a permissive mode might be a way out.
Martin
Hope this is constructive
Dave
