1. 18 Apr, 2019 3 commits
    • Thomas Haller's avatar
      shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core · 284ac92e
      Thomas Haller authored
      "libnm-core" implements common functionality for "NetworkManager" and
      "libnm".
      
      Note that clients like "nmcli" cannot access the internal API provided
      by "libnm-core". So, if nmcli wants to do something that is also done by
      "libnm-core", , "libnm", or "NetworkManager", the code would have to be
      duplicated.
      
      Instead, such code can be in "libnm-libnm-core-{intern|aux}.la".
      Note that:
      
        0) "libnm-libnm-core-intern.la" is used by libnm-core itsself.
           On the other hand, "libnm-libnm-core-aux.la" is not used by
           libnm-core, but provides utilities on top of it.
      
        1) they both extend "libnm-core" with utlities that are not public
           API of libnm itself. Maybe part of the code should one day become
           public API of libnm. On the other hand, this is code for which
           we may not want to commit to a stable interface or which we
           don't want to provide as part of the API.
      
        2) "libnm-libnm-core-intern.la" is statically linked by "libnm-core"
           and thus directly available to "libnm" and "NetworkManager".
           On the other hand, "libnm-libnm-core-aux.la" may be used by "libnm"
           and "NetworkManager".
           Both libraries may be statically linked by libnm clients (like
           nmcli).
      
        3) it must only use glib, libnm-glib-aux.la, and the public API
           of libnm-core.
           This is important: it must not use "libnm-core/nm-core-internal.h"
           nor "libnm-core/nm-utils-private.h" so the static library is usable
           by nmcli which couldn't access these.
      
      Note that "shared/nm-meta-setting.c" is an entirely different case,
      because it behaves differently depending on whether linking against
      "libnm-core" or the client programs. As such, this file must be compiled
      twice.
      
      (cherry picked from commit af07ed01)
      284ac92e
    • 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
    • Thomas Haller's avatar
      shared: move udev helper to separate directory "shared/nm-udev-aux" · 95621586
      Thomas Haller authored
      We built (among others) two libraries from the sources in "shared/nm-utils":
      "libnm-utils-base.la" and "libnm-utils-udev.la".
      
      It's confusing. Instead use directories so there is a direct
      correspondence between these internal libraries and the source files.
      
      (cherry picked from commit 2973d682)
      95621586
  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. 12 Feb, 2019 2 commits
  5. 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
  6. 20 Dec, 2018 1 commit
  7. 17 Sep, 2018 1 commit
  8. 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
  9. 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
  10. 10 Jul, 2018 1 commit
  11. 28 Jun, 2018 1 commit
  12. 31 May, 2018 2 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
  13. 23 May, 2018 1 commit
  14. 14 May, 2018 1 commit
    • Lubomir Rintel's avatar
      build: qualify plugin dir name with a version string · 320422e4
      Lubomir Rintel authored
      This makes package updates more robust, avoiding in-place replaces of
      the plugins.
      
      Previously, if an upgrade transaction was terminated, NetworkManager
      library could end up being of a different version than the plugins.
      If the user was unfortunate enough to connect using a connection that
      required a plugin (say, Wi-Fi), he would be left without a network
      connection making it somewhat inconvenient to recover from the botched
      upgrade.
      
      This makes the whole situation a little bit less sad.
      
      The VPN plugins are kept where they always have been -- the path is not
      qualified with a version number.
      320422e4
  15. 11 May, 2018 2 commits
    • Thomas Haller's avatar
      tests: use libnm via pygobject in tools/test-networkmanager-service.py · 9628aabc
      Thomas Haller authored
      tools/test-networkmanager-service.py is our NetworkManager stub server.
      
      NetworkManager uses libnm(-core) heavily, for example to decide whether
      a connection verifies (nm_connection_verify()) and for normalizing
      connections (nm_connection_normalize()).
      
      If the stub server wants to mimic NetworkManager, it also must use these
      function. Luckily, we already can do so, by loading libnm using python
      GObject introspection.
      
      We already correctly set GI_TYPELIB_PATH search path, so that the
      correct libnm is loaded -- provided that we build with introspection
      enabled.
      
      We still need to gracefully fail, if starting the stub server fails.
      That requries some extra effort. If the stub server notices that
      something is missing, it shall exit with status 77. That will cause
      the tests to g_test_skip().
      9628aabc
    • Harry Mallon's avatar
  16. 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
  17. 09 May, 2018 1 commit
  18. 30 Apr, 2018 1 commit
  19. 13 Apr, 2018 1 commit
  20. 12 Apr, 2018 3 commits
  21. 26 Mar, 2018 1 commit
  22. 08 Mar, 2018 1 commit
    • Benjamin Berg's avatar
      Add calls to g_simple_async_result_set_check_cancellable · 26c215e2
      Benjamin Berg authored
      If an operation is cancelled through the GCancellable, then the idiom is
      that the operation is always cancelled, even if it has finished
      successfully. To ensure this is the case, add calls to
      g_simple_async_result_set_check_cancellable everywhere.
      
      Without this, e.g. gnome-control-center will crash when switching away
      from the power panel quickly, as the NMClient creation finishes
      asynchronously and g-c-c assume that G_IO_ERROR_CANCELLED is returned to
      ensure it doesn't access the now invalid user_data parameter.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=794088
      26c215e2
  23. 08 Feb, 2018 2 commits
    • Lubomir Rintel's avatar
      all: fix -Wcast-function-type warnings · ee916a1e
      Lubomir Rintel authored
      GCC 8.0's -Wcast-function-type objects casting function pointers to ones
      with incompatible prototypes. Sometimes we do that on purpose though.
      
      Notably, the g_source_set_callback()'s func argument can point to functions
      of various prototypes. Also, libnm-glib/nm-remote-connection is perhaps
      just not worth reworking, that would just be a waste of time.
      
      A cast to void(*)(void) avoids the GCC warning, let's use it.
      ee916a1e
    • Lubomir Rintel's avatar
      libnm/vpn-plugin: avoid bad function pointer type casts · 7f7207f3
      Lubomir Rintel authored
      This makes GCC 8.0 unhappy and it is probably right about that -- it's more
      difficult to get things wrong when the function prototypes actually match.
      7f7207f3
  24. 07 Feb, 2018 2 commits
  25. 18 Jan, 2018 1 commit
  26. 16 Jan, 2018 1 commit
  27. 12 Jan, 2018 1 commit
  28. 11 Jan, 2018 1 commit
  29. 10 Jan, 2018 3 commits