| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These macros would fail with infinite recursion if used twice for the
same variable, for example
AX_COMPILER_FLAGS_CFLAGS([WARN_CFLAGS], ... some options ...)
AX_COMPILER_FLAGS_CFLAGS([WARN_CFLAGS], ... more options ...)
In particular, invoking AX_COMPILER_FLAGS, followed by
AX_COMPILER_FLAGS_CFLAGS with more "yes" options has this failure mode.
This is because the first time through the macro, we define
ax_warn_cflags_variable = "WARN_CFLAGS" as expected. The second time,
because the first parameter is underquoted, its value is substituted
before calling m4_define, so we inadvertently define
WARN_CFLAGS = "WARN_CFLAGS". The next time WARN_CFLAGS is mentioned,
attempts to expand it will recurse forever, because m4 does not
special-case a macro that appears in its own expansion like cpp does.
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
These went against the whole concept of providing a baseline set of
warnings which is set by the module maintainer, since it allowed
individual developers to opt out of certain classes of warning.
Remove them, leaving the ‘no’, ‘yes’ and ‘error’ levels. This maintains
API compatibility of the macros by marking various EXTRA-* variables as
unused, but still handling them, and merging their values with the
preceding EXTRA-* variables. For example, all extra ‘maximum’ and
‘error’ flags are now included in the ‘yes’ level of warnings.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
g-ir-scanner is a tool used within a lot of GNOME projects to generate
introspection data from C APIs. It has a couple of warning flags (and is
not likely to gain any more in the future), and chaining them to
--enable-compile-warnings would be useful.
Integrate AX_COMPILER_FLAGS_GIR into AX_COMPILER_FLAGS so that it’s
enabled by default.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
The build process requires python, the python StringTemplate module,
and preferably SCons. A make-based build exists, but it is really slow
and awkward, compared to the SConstruct file.
|