1. 18 Apr, 2019 1 commit
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · d984b2ce
      Thomas Haller authored
      From the files under "shared/nm-utils" we build an internal library
      that provides glib-based helper utilities.
      
      Move the files of that basic library to a new subdirectory
      "shared/nm-glib-aux" and rename the helper library "libnm-core-base.la"
      to "libnm-glib-aux.la".
      
      Reasons:
      
       - the name "utils" is overused in our code-base. Everything's an
         "utils". Give this thing a more distinct name.
      
       - there were additional files under "shared/nm-utils", which are not
         part of this internal library "libnm-utils-base.la". All the files
         that are part of this library should be together in the same
         directory, but files that are not, should not be there.
      
       - the new name should better convey what this library is and what is isn't:
         it's a set of utilities and helper functions that extend glib with
         funcitonality that we commonly need.
      
      There are still some files left under "shared/nm-utils". They have less
      a unifying propose to be in their own directory, so I leave them there
      for now. But at least they are separate from "shared/nm-glib-aux",
      which has a very clear purpose.
      
      (cherry picked from commit 80db06f7)
      d984b2ce
  2. 03 Apr, 2019 1 commit
  3. 19 Mar, 2019 1 commit
    • Lubomir Rintel's avatar
      all: goodbye libnm-glib · 1de8383a
      Lubomir Rintel authored
      This removes libnm-glib, libnm-glib-vpn, and libnm-util for good.
      The it has been replaced with libnm since NetworkManager 1.0, disabled
      by default since 1.12 and no up-to-date distributions ship it for years
      now.
      
      Removing the libraries allows us to:
      
      * Remove the horrible hacks that were in place to deal with accidental use
        of both the new and old library in a single process.
      * Relief the translators of maintenance burden of similar yet different
        strings.
      * Get rid of known bad code without chances of ever getting fixed
        (libnm-glib/nm-object.c and libnm-glib/nm-object-cache.c)
      * Generally lower the footprint of the releases and our workspace
      
      If there are some really really legacy users; they can just build
      libnm-glib and friends from the NetworkManager-1.16 distribution. The
      D-Bus API is stable and old libnm-glib will keep working forever.
      
      https://github.com/NetworkManager/NetworkManager/pull/308
      1de8383a
  4. 07 Mar, 2019 2 commits
  5. 12 Feb, 2019 1 commit
  6. 06 Feb, 2019 1 commit
    • Thomas Haller's avatar
      all: don't use "static inline" in source files · d25ed082
      Thomas Haller authored
      For static functions inside a module, the compiler determines on its own
      whether to inline the function.
      
      Also, "inline" was used at some places that don't immediatly look like
      candidates for inlining. It was most likely a copy&paste error.
      d25ed082
  7. 05 Feb, 2019 1 commit
    • Thomas Haller's avatar
      build/meson: add intermediate shared/nm-utils base library · c67ebc8a
      Thomas Haller authored
      Like also done for autotools, create and use intermediate libraries
      from "shared/nm-utils/".
      
      Also, replace "shared_dep" by "shared_nm_utils_base_dep". We don't
      need super fine-grained selection of what we link. We can always
      link in "shared/libnm-utils-base.a", and let the linker throw away
      unsed parts.
      c67ebc8a
  8. 20 Dec, 2018 1 commit
  9. 29 Nov, 2018 1 commit
    • Lubomir Rintel's avatar
      all: say Wi-Fi instead of "wifi" or "WiFi" · b385ad01
      Lubomir Rintel authored
      Correct the spelling across the *entire* tree, including translations,
      comments, etc. It's easier that way.
      
      Even the places where it's not exposed to the user, such as tests, so
      that we learn how is it spelled correctly.
      b385ad01
  10. 17 Sep, 2018 1 commit
  11. 13 Sep, 2018 1 commit
  12. 12 Sep, 2018 1 commit
  13. 04 Sep, 2018 1 commit
  14. 28 Aug, 2018 1 commit
  15. 22 Aug, 2018 1 commit
  16. 10 Aug, 2018 1 commit
    • Thomas Haller's avatar
      libnm/trivial: cleanup variable names in settings' class-init functions · 23adc373
      Thomas Haller authored
      - Don't use @parent_class name. This local variable (and @object_class) is
        the class instance up-cast to the pointer types of the parents. The point
        here is not that it is the direct parent. The point is, that it's the
        NMSettingClass type.
        Also, it can only be used inconsistently, in face of NMSettingIP4Config,
        who's parent type is NMSettingIPConfig. Clearly, inside
        nm-setting-ip4-config.c we wouldn't want to use the "parent_class"
        name. Consistently rename @parent_class to @setting_class.
      
      - Also rename the pointer to the own class to @klass. "setting_class" is also the
        wrong name for that, because the right name would be something like
        "setting_6lowpan_class".
        However, "klass" is preferred over the latter, because we commonly create new
        GObject implementations by copying an existing one. Generic names like "klass"
        and "self" inside a type implementation make that simpler.
      
      - drop useless comments like
      
           /* virtual functions */
           /* Properties */
      
        It's better to logically and visually structure the code, and avoid trival
        remarks about that. They only end up being used inconsistently. If you
        even need a stronger visual separator, then an 80 char /****/ line
        should be preferred.
      23adc373
  17. 17 Jul, 2018 1 commit
    • Thomas Haller's avatar
      build: create "config-extra.h" header instead of passing directory variables via CFLAGS · a75ab799
      Thomas Haller authored
      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 e5d1a713
         and commit d63cf1ef).
         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
      a75ab799
  18. 11 Jul, 2018 1 commit
    • Thomas Haller's avatar
      all: don't use gchar/gshort/gint/glong but C types · e1c7a2b5
      Thomas Haller authored
      We commonly don't use the glib typedefs for char/short/int/long,
      but their C types directly.
      
          $ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          587
          $ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
          21114
      
      One could argue that using the glib typedefs is preferable in
      public API (of our glib based libnm library) or where it clearly
      is related to glib, like during
      
        g_object_set (obj, PROPERTY, (gint) value, NULL);
      
      However, that argument does not seem strong, because in practice we don't
      follow that argument today, and seldomly use the glib typedefs.
      Also, the style guide for this would be hard to formalize, because
      "using them where clearly related to a glib" is a very loose suggestion.
      
      Also note that glib typedefs will always just be typedefs of the
      underlying C types. There is no danger of glib changing the meaning
      of these typedefs (because that would be a major API break of glib).
      
      A simple style guide is instead: don't use these typedefs.
      
      No manual actions, I only ran the bash script:
      
        FILES=($(git ls-files '*.[hc]'))
        sed -i \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>  /\1   /g' \
            -e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
            "${FILES[@]}"
      e1c7a2b5
  19. 28 Jun, 2018 1 commit
  20. 31 May, 2018 3 commits
    • Thomas Haller's avatar
      build/meson: fix meson build for shared files · f445128a
      Thomas Haller authored
      The files in shared/nm-utils are not compiled as one static library,
      instead each subproject that needs (parts of) them, re-compiles the
      files individually.
      
      The major reason for that is, because we might have different compile
      flags, depending on whether we build libnm-core or
      libnm-util/libnm-glib. Actually, I think that is not really the case,
      and maybe this should be refactored, to indeed build them all as a
      static library first.
      
      Anyway, libnm-util, libnm-glib, clients' common lib, they all need a
      different set of shared files that they should compile. Refactor
      "shared/meson.build" to account for that and handle it like autotools
      does.
      
      Another change is, that "shared_c_siphash_dep" no longer advertises
      "include_directories: include_directories('c-siphash/src')". We don't
      put c-siphash.h into the include search path. Users who need it, should
      include it via "#include <c-siphash/src/c-siphash.h>". The only exception
      is when building shared_n_acd library, which is not under our control.
      f445128a
    • Thomas Haller's avatar
      build: use default NM_BUILD_* defines for tests · b7426e91
      Thomas Haller authored
      Use two common defines NM_BUILD_SRCDIR and NM_BUILD_BUILDDIR
      for specifying the location of srcdir and builddir.
      
      Note that this is only relevant for tests, as they expect
      a certain layout of the directories, to find files that concern
      them.
      b7426e91
    • Thomas Haller's avatar
      e5d1a713
  21. 24 May, 2018 1 commit
  22. 10 May, 2018 1 commit
    • Lubomir Rintel's avatar
      all: use the elvis operator wherever possible · e69d3869
      Lubomir Rintel authored
      Coccinelle:
      
        @@
        expression a, b;
        @@
        -a ? a : b
        +a ?: b
      
      Applied with:
      
        spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
      
      With some manual adjustments on spots that Cocci didn't catch for
      reasons unknown.
      
      Thanks to the marvelous effort of the GNU compiler developer we can now
      spare a couple of bits that could be used for more important things,
      like this commit message. Standards commitees yet have to catch up.
      e69d3869
  23. 30 Apr, 2018 1 commit
  24. 12 Apr, 2018 2 commits
  25. 08 Feb, 2018 1 commit
  26. 07 Feb, 2018 1 commit
  27. 23 Jan, 2018 2 commits
    • Thomas Haller's avatar
      version: rename macro NM_VERSION_CUR_STABLE to NM_API_VERSION · 4da1480c
      Thomas Haller authored
      NM_API_VERSION is a better name. It's not the current stable
      version, but the version number of the API which the current
      NM_VERSION provides. In practice, NM_API_VERSION is either identical
      to NM_VERSION (in case of a release) or NM_VERSION is a development
      version leading up the the upcoming NM_API_VERSION.
      
      For example, with the new name the check
      
        #if NM_VERSION != NM_API_VERSION
        # warning this is an development version
        #endif
      
      makes more sense.
      4da1480c
    • Thomas Haller's avatar
      version: combine NM_VERSION_CUR_STABLE and NM_VERSION_NEXT_STABLE · 8a040c68
      Thomas Haller authored
      We don't need to have two version defines "CUR" and "NEXT".
      
      The main purpose of these macros (if not their only), is to
      make NM_AVAILABLE_IN_* and NM_DEPRECATED_IN_* macros work.
      
      1) At the precise commit of a release, "CUR" and "NEXT" must be identical,
      because whenever the user configures NM_VERSION_MIN_REQUIRED and
      NM_VERSION_MAX_ALLOWED, then they both compare against the current
      version, at which point "CUR" == "NEXT".
      
      2) Every other commit aside the release, is a development version that leads
      up the the next coming release. But as far as versioning is concerned, such
      a development version should be treated like that future release. It's unstable
      API and it may or may not be close to later API of the release. But
      we shall treat it as that version. Hence, also in this case, we want to
      set both "NM_VERSION_CUR_STABLE" and again NEXT to the future version.
      
      This makes NM_VERSION_NEXT_STABLE redundant.
      
      Previously, the separation between current and next version would for
      example allow that NM_VERSION_CUR_STABLE is the previously release
      stable API, and NM_VERSION_NEXT_STABLE is the version of the next upcoming
      stable API. So, we could allow "examples" to make use of development
      API, but other(?) internal code still restrict to unstable API. But it's
      unclear which other code would want to avoid current development.
      
      Also, the points 1) and 2) were badly understood. Note that for our
      previousy releases, we usually didn't bump the macros at the stable
      release (and if we did, we didn't set them to be the same). While using
      two macros might be more powerful, it is hard to grok and easy to
      forget to bump the macros a the right time. One macro shall suffice.
      
      All this also means, that *immediately* after making a new release, we shall
      bump the version number in `configure.ac` and "NM_VERSION_CUR_STABLE".
      8a040c68
  28. 18 Jan, 2018 1 commit
  29. 11 Jan, 2018 1 commit
  30. 10 Jan, 2018 3 commits
    • Thomas Haller's avatar
      build/meson: unconditionally use linker version scripts · 349861ce
      Thomas Haller authored
      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.
      349861ce
    • Inigo Martínez's avatar
      meson: Use string variables extensively · 50930ed1
      Inigo Martínez authored
      The strings holding the names used for libraries have also been
      moved to different variables. This way they would be less error
      as these variables can be reused easily and any typing error
      would be quickly detected.
      50930ed1
    • Inigo Martínez's avatar
      meson: Improve dependency system · 5e16bcf2
      Inigo Martínez authored
      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.
      5e16bcf2
  31. 08 Jan, 2018 3 commits
    • Thomas Haller's avatar
      libnm: drop libnm-util/nm-setting-template.[hc] · 29e566cc
      Thomas Haller authored
      These files are a template how to add a new nm-setting-* implementation.
      
      We are not going to add new files to the deprecated libnm-util library,
      hence a template for libnm-util is pointless.
      
      libnm-core doesn't have a corresponding template file. Personally, I
      don't think such a template are a great idea either, because
      
        - People are not aware that it exists. Hence, it's unused, badly
          maintained and quite possibly does not follow current best practice.
        - Just copy an actual settings implementation and start from there.
          That seems better to me than having a template.
      29e566cc
    • Thomas Haller's avatar
      tests: use NMTST_EXPECT*() macros · 25ade397
      Thomas Haller authored
      Tests are commonly created via copy&paste. Hence, it's
      better to express a certain concept explicitly via a function
      or macro. This way, the implementation of the concept can be
      adjusted at one place, without requiring to change all the callers.
      
      Also, the macro is shorter, and brevity is better for tests
      so it's easier to understand what the test does. Without being
      bothered by noise from the redundant information.
      
      Also, the macro knows better which message to expect. For example,
      messages inside "src" are prepended by nm-logging.c with a level
      and a timestamp. The expect macro is aware of that and tests for it
      
        #define NMTST_EXPECT_NM_ERROR(msg)      NMTST_EXPECT_NM (G_LOG_LEVEL_MESSAGE, "*<error> [*] "msg)
      
      This again allows the caller to ignore this prefix, but still assert
      more strictly.
      25ade397
    • Thomas Haller's avatar
      build: refine the NETWORKMANAGER_COMPILATION define · 22ef6a50
      Thomas Haller authored
      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.
      22ef6a50