Commit Graph

6 Commits

Author SHA1 Message Date
Thomas Haller
a75ab799e4 build: create "config-extra.h" header instead of passing directory variables via CFLAGS
1) the command line gets shorter. I frequently run `make V=1` to see
   the command line arguments for the compiler, and there is a lot
   of noise.

2) define each of these variables at one place. This makes it easy
   to verify that for all compilation units, a particular
   define has the same value. Previously that was not obvious or
   even not the case (see commit e5d1a71396
   and commit d63cf1ef2f).
   The point is to avoid redundancy.

3) not all compilation units need all defines. In fact, most modules
   would only need a few of these defines. We aimed to pass the necessary
   minium of defines to each compilation unit, but that was non-obvious
   to get right and often we set a define that wasn't used. See for example
   "src_settings_plugins_ibft_cppflags" which needlessly had "-DSYSCONFDIR".
   This question is now entirely avoided by just defining all variables in
   a header. We don't care to find the minimum, because every component
   gets anyway all defines from the header.

4) this also avoids the situation, where a module that previously did
   not use a particular define gets modified to require it. Previously,
   that would have required to identify the missing define, and add
   it to the CFLAGS of the complation unit. Since every compilation
   now includes "config-extra.h", all defines are available everywhere.

5) the fact that each define is now available in all compilation units
   could be perceived as a downside. But it isn't, because these defines
   should have a unique name and one specific value. Defining the same
   name with different values, or refer to the same value by different
   names is a bug, not a desirable feature. Since these defines should
   be unique accross the entire tree, there is no problem in providing
   them to every compilation unit.

6) the reason why we generate "config-extra.h" this way, instead of using
   AC_DEFINE() in configure.ac, is due to the particular handling of
   autoconf for directory variables. See [1].
   With meson, it would be trivial to put them into "config.h.meson".
   While that is not easy with autoconf, the "config-extra.h" workaround
   seems still preferable to me.

[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Installation-Directory-Variables.html
2018-07-17 17:46:39 +02:00
Thomas Haller
34cb6f9877 build/meson: use variables for ldflags and linker-script 2018-01-11 12:46:01 +01:00
Thomas Haller
349861ceec build/meson: unconditionally use linker version scripts
We also unconditionally use them with autotools.
Also, the detection for have_version_script does
not seem correct to me. At least, it didn't work
with clang.
2018-01-10 12:31:44 +01:00
Iñigo Martínez
5e16bcf268 meson: Improve dependency system
Some targets are missing dependencies on some generated sources in
the meson port. These makes the build to fail due to missing source
files on a highly parallelized build.

These dependencies have been resolved by taking advantage of meson's
internal dependencies which can be used to pass source files,
include directories, libraries and compiler flags.

One of such internal dependencies called `core_dep` was already in
use. However, in order to avoid any confusion with another new
internal dependency called `nm_core_dep`, which is used to include
directories and source files from the `libnm-core` directory, the
`core_dep` dependency has been renamed to `nm_dep`.

These changes have allowed minimizing the build details which are
inherited by using those dependencies. The parallelized build has
also been improved.
2018-01-10 12:20:17 +01:00
Thomas Haller
22ef6a507a build: refine the NETWORKMANAGER_COMPILATION define
Note that:

 - we compile some source files multiple times. Most notably those
   under "shared/".

 - we include a default header "shared/nm-default.h" in every source
   file. This header is supposed to setup a common environment by defining
   and including parts that are commonly used. As we always include the
   same header, the header must behave differently depending
   one whether the compilation is for libnm-core, NetworkManager or
   libnm-glib. E.g. it must include <glib/gi18n.h> or <glib/gi18n-lib.h>
   depending on whether we compile a library or an application.

For that, the source files need the NETWORKMANAGER_COMPILATION #define
to behave accordingly.

Extend the define to be composed of flags. These flags are all named
NM_NETWORKMANAGER_COMPILATION_WITH_*, they indicate which part of the
build are available. E.g. when building libnm-core.la itself, then
WITH_LIBNM_CORE, WITH_LIBNM_CORE_INTERNAL, and WITH_LIBNM_CORE_PRIVATE
are available. When building NetworkManager, WITH_LIBNM_CORE_PRIVATE
is not available but the internal parts are still accessible. When
building nmcli, only WITH_LIBNM_CORE (the public part) is available.
This granularily controls the build.
2018-01-08 12:38:53 +01:00
Iñigo Martínez
03637ad8b5 build: add initial support for meson build system
meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.

[thaller@redhat.com: rebased patch and adjusted for iwd support]

https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00022.html
2017-12-13 15:48:50 +01:00