All current users of NM_IN_SET() would rather use short-circuit evalation
(or don't care). It seems that doing it by default seems favorable.
The only downside is, that this might have somewhat unexpected behavior
to a user who expects a regular function (which would evaluate always
all arguments).
Fixes: 7860ef959a
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Add a macro to insert the necessary compiler/linker magic to add a
copy of an existing symbol to an older version. Also, update
check-exports.sh to be able to check for such symbols by listed them
commented-out in the appropriate section.
[thaller@redhat.com: patch modified]
Related: https://bugzilla.gnome.org/show_bug.cgi?id=742993
Even if asserts are not enabled, still let the compiler see what we would
assert. Otherwise, we get warnings about unused variables or we migth miss
compile errors inside nm_assert().
We already have "nm-utils*.h" and "NetworkManagerUtils.h" headers. Rename
"include/nm-utils-internal.h" to "nm-macros-internal.h". I think that
name is better, because this file is header-only, internal, and
repository-wide.
Also, it will never contain non-header-only declarations because
there is no backing object file under "include/".
It will only contain macros and inline functions.
