1. 27 May, 2019 1 commit
  2. 23 May, 2019 3 commits
    • Thomas Haller's avatar
      libnm: add "libnm-core/nm-team-utils.h" · 539dfbcc
      Thomas Haller authored
      539dfbcc
    • Thomas Haller's avatar
      shared: add "shared/nm-glib-aux/nm-value-type.h" · e64fdeea
      Thomas Haller authored
      Glib has GValue which used for boxing value.
      
      Add NMValueType enum, which has a similar purpose, but it's much more
      limited.
      
      - contrary to GValue, the type must be tracked separately from the
        user-data. That is, the "user-data" is only a pointer of appropriate
        type, and the knowledge of the actual NMValueType is kept separately.
        This will be used to have a static list of meta-data that knows the
        value types, but keeping the values independent of this type
        information. With GValue this would not be possible.
      
      - the use case is much more limited. Just support basic integers,
        boolean and strings. Nothing fancy.
      
      Note that we already do something similar at muliple places. See for
      example NMVariantAttributeSpec and nm_utils_team_link_watcher_to_string().
      These could/should instead use NMValueType.
      e64fdeea
    • Thomas Haller's avatar
      shared: add "shared/nm-glib-aux/nm-json-aux.h" · f84e6237
      Thomas Haller authored
      This will be a set of JSON related utilities, that are independent of
      libjansson.
      f84e6237
  3. 22 May, 2019 12 commits
  4. 19 May, 2019 5 commits
  5. 18 May, 2019 1 commit
    • Thomas Haller's avatar
      platform/tests: rename platform's "test-general.c" · 041aa3d6
      Thomas Haller authored
      Older versions of meson don't like building multiple artifacts
      with the same name (even if they are in different directories). We
      have multiple tests called "test-general.c", and it would be natural
      to compile a test binary of the same name.
      
        Meson encountered an error in file src/tests/meson.build, line 14, column 2:
        Tried to create target "test-general", but a target of that name already exists.
      
      It's generally a bad idea to have in our source tree multiple files with the
      same name. Rename the test.
      
      Fixes: 16cd84d3 ('build/meson: rename platform tests to use same name as autotools'):
      041aa3d6
  6. 17 May, 2019 1 commit
  7. 12 May, 2019 1 commit
  8. 07 May, 2019 1 commit
  9. 03 May, 2019 1 commit
    • Lubomir Rintel's avatar
      build: fix an out-of-tree build · e33a995d
      Lubomir Rintel authored
        make[3]: Entering directory 'NetworkManager/_build/sub'
          CC       clients/cli/nmcli-common.o
        cc1: error: ./clients/common: No such file or directory [-Werror=missing-include-dirs]
        cc1: all warnings being treated as errors
      
      The only generated header in $builddir/clients/common is settings-docs.h
      and only libnmc.la needs it. Include the directory on the command line
      only when we know it exists.
      e33a995d
  10. 26 Apr, 2019 1 commit
  11. 25 Apr, 2019 2 commits
    • Thomas Haller's avatar
      shared/tests: add tests for libnm-core-aux · 7a25f67a
      Thomas Haller authored
      These tests cannot (easily) be under "shared/nm-libnm-core-aux/tests"
      because libnm/libnm-core requires code under shared while
      "nm-libnm-core-aux" requires libnm/libnm-core. With autotools that is
      not problem, but with meson we include sub directories in a particular
      order and there is no way to foward declare stuff (AFAIK). To avoid
      the circular dependency, add the tests to "clients/common/tests", which
      is always built last.
      7a25f67a
    • Thomas Haller's avatar
      14b94e6a
  12. 18 Apr, 2019 10 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 "nm-dbus-compat.h" header to "nm-std-aux/nm-dbus-compat.h" · 87f7e684
      Thomas Haller authored
      (cherry picked from commit 81833358)
      87f7e684
    • 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
    • Thomas Haller's avatar
      shared: split C-only helper "shared/nm-std-aux" utils out of "shared/nm-utils" · 0a6f21fb
      Thomas Haller authored
      "shared/nm-utils" contains general purpose utility functions that only
      depend on glib (and extend glib with some helper functions).
      
      We will also add code that does not use glib, hence it would be good
      if the part of "shared/nm-utils" that does not depend on glib, could be
      used by these future projects.
      
      Also, we use the term "utils" everywhere. While that covers the purpose
      and content well, having everything called "nm-something-utils" is not
      great. Instead, call this "nm-std-aux", inspired by "c-util/c-stdaux".
      
      (cherry picked from commit b434b9ec)
      0a6f21fb
    • Thomas Haller's avatar
      shared: build helper "libnm-libnm-core-{intern|aux}.la" library for libnm-core · af07ed01
      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.
      af07ed01
    • Thomas Haller's avatar
    • Thomas Haller's avatar
      shared: move most of "shared/nm-utils" to "shared/nm-glib-aux" · 80db06f7
      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.
      80db06f7
    • Thomas Haller's avatar
      shared: move udev helper to separate directory "shared/nm-udev-aux" · 2973d682
      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.
      2973d682
    • Thomas Haller's avatar
      shared: split C-only helper "shared/nm-std-aux" utils out of "shared/nm-utils" · b434b9ec
      Thomas Haller authored
      "shared/nm-utils" contains general purpose utility functions that only
      depend on glib (and extend glib with some helper functions).
      
      We will also add code that does not use glib, hence it would be good
      if the part of "shared/nm-utils" that does not depend on glib, could be
      used by these future projects.
      
      Also, we use the term "utils" everywhere. While that covers the purpose
      and content well, having everything called "nm-something-utils" is not
      great. Instead, call this "nm-std-aux", inspired by "c-util/c-stdaux".
      b434b9ec
  13. 16 Apr, 2019 1 commit
    • Lubomir Rintel's avatar
      all: goodbye libnm-glib · 5801f89f
      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
      5801f89f