1. 16 Mar, 2018 1 commit
  2. 15 Feb, 2018 1 commit
    • Beniamino Galvani's avatar
      build: allow building with address sanitizer only for executables · 0af2762c
      Beniamino Galvani authored
      Shared libraries built with sanitizers are a bit inconvenient to use
      because they require that any application linking to them is run with
      libasan preloaded using LD_PRELOAD. This limitation makes the
      sanitizer support less useful because applications will refuse to
      start unless there is a special environment variable set.
      
      Let's turn the --enable-address-sanitizer configure flag into
      --with-address-sanitizer=yes|no|exec so that is possible to enable
      asan only for executables.
      0af2762c
  3. 07 Feb, 2018 1 commit
  4. 23 Jan, 2018 2 commits
    • Thomas Haller's avatar
      version: drop NM_VERSION_MAX_ALLOWED defines for internal build · 9ef17869
      Thomas Haller authored
      It already defaults to the right value. We only need to define
      NM_VERSION_MIN_REQUIRED, so that parts of our internal build
      can make use of deprecated API.
      9ef17869
    • 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
  5. 18 Jan, 2018 1 commit
  6. 10 Jan, 2018 3 commits
  7. 08 Jan, 2018 1 commit
    • 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
  8. 02 Jan, 2018 2 commits
  9. 18 Dec, 2017 1 commit
  10. 13 Dec, 2017 1 commit
  11. 30 Oct, 2017 1 commit
  12. 17 Mar, 2017 7 commits
  13. 09 Mar, 2017 1 commit
    • Thomas Haller's avatar
      include: use double-quotes to include our own headers · 831286df
      Thomas Haller authored
      In practice, this should only matter when there are multiple
      header files with the same name. That is something we try
      to avoid already, by giving headers a distinct name.
      
      When building NetworkManager itself, we clearly want to use
      double-quotes for including our own headers.
      But we also want to do that in our public headers. For example:
      
        ./a.c
          #include <stdio.h>
          #include <nm-1.h>
          void main() {
              printf ("INCLUDED %s/nm-2.h\n", SYMB);
          }
      
        ./1/nm-1.h
          #include <nm-2.h>
      
        ./1/nm-2.h
          #define SYMB "1"
      
        ./2/nm-2.h
          #define SYMB "2"
      
      $ cc -I./2 -I./1 ./a.c
      $ ./a.out
      INCLUDED 2/nm-2.h
      
      Exceptions to this are
        - headers in "shared/nm-utils" that include <NetworkManager.h>. These
          headers are copied into projects and hence used like headers owned by
          those projects.
        - examples/C
      831286df
  14. 02 Mar, 2017 1 commit
  15. 23 Feb, 2017 1 commit
  16. 13 Feb, 2017 1 commit
    • Thomas Haller's avatar
      build: combine handling of setting docs and man pages · b599f1b7
      Thomas Haller authored
      Building the man pages via xsltproc requires "docbook.xsl"
      which is part of docbook.
      
      Previously, we would build the man pages solely based on
      "--enable-introspection", which checks for the presence of
      xsltproc, but not docbook. This can lead to build failure
      when docbook is not available, but "--enable-introspection"
      is given.
      
      Instead of adding yet another configure option to fine-tune
      and say "--with-docbook --disable-gtk-doc", just simplify it.
      
      Now, documentation (both man pages and setting docs) will be generated
      with "--enable-gtk-doc" and "--enable-introspection".
      If the documentation is not about to be generated, pre-generated docs
      will be installed if they are available. That is commonly the case
      with a source tarball, but not with a git checkout.
      Finally, if documentation is nither generated nor pre-generated,
      no documentation will be installed *duh*.
      
      This removes the possibility to treat man pages separate from settings
      docs. Now you either generate both, install both pre-generated, or don't
      get any of them.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=778551
      b599f1b7
  17. 16 Jan, 2017 1 commit
  18. 15 Dec, 2016 1 commit
  19. 12 Dec, 2016 1 commit
  20. 28 Nov, 2016 1 commit
    • Thomas Haller's avatar
      build: fix gtk-doc/introspection handling for build · a80ba4ea
      Thomas Haller authored
      - `make dist` requires --enable-gtk-doc --enable-introspection --with-libnm-glib
      - --enable-gtk-doc requires --enable-introspection
      - --with-nmcli requires either --enable-introspection or pregenerated
         settings-docs.c files from the dist tarball. It does not require
         --enable-gtk-doc.
      
      There is a bit of a problem in that --enable-introspection requires
      now xsltproc. However, gobject-introspection does itself not depend
      on xsltproc. So, more correct might be a special --enable-doc argument,
      that combines --enable-introspection --with-xsltproc. Anyway, that
      seems to make it more complicated then it already is so just implicitly
      (and surprisingly?) require xsltproc with --enable-introspection.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=775003
      a80ba4ea
  21. 24 Nov, 2016 1 commit
  22. 23 Nov, 2016 1 commit
  23. 10 Nov, 2016 1 commit
    • Lubomir Rintel's avatar
      libnm: use the o.fd.DBus.ObjectManager API for object management · 1f5b48a5
      Lubomir Rintel authored
      This speeds up the initial object tree load significantly. Also, it
      reduces the object management complexity by shifting the duties to
      GDBusObjectManager.
      
      The lifetime of all NMObjects is now managed by the NMClient via the
      object manager. The NMClient creates the NMObjects for GDBus objects,
      triggers the initialization and serves as an object registry (replaces
      the nm-cache).
      
      The ObjectManager uses the o.fd.DBus.ObjectManager API to learn of the
      object creation, removal and property changes. It takes care of the
      property changes so that we don't have to and lets us always see a
      consistent object state.  Thus at the time we learn of a new object we
      already know its properties.
      
      The NMObject unfortunately can't be made synchronously initializable as
      the NMRemoteConnection's settings are not managed with standard
      o.fd.DBus Properties and ObjectManager APIs and thus are not known to
      the ObjectManager.  Thus most of the asynchronous object property
      changing code in nm-object.c is preserved. The objects notify the
      properties that reference them of their initialization in from their
      init_finish() methods, thus the asynchronously created objects are not
      allowed to fail creation (or the dependees would wait forever). Not a
      problem -- if a connection can't get its Settings, it's either invisible
      or being removed (presumably we'd learn of the removal from the object
      manager soon).
      
      The NMObjects can't be created by the object manager itself, since we
      can't determine the resulting object type in proxy_type() yet (we can't
      tell from the name and can't access the interface list). Therefore the
      GDBusObject is coupled with a NMObject later on.
      
      Lastly, now that all the objects are managed by the object manager, the
      NMRemoteSettings and NMManager go away when the daemon is stopped. The
      complexity of dealing with calls to NMClient that would require any of
      the resources that these objects manage (connection or device lists,
      etc.) had to be moved to NMClient. The bright side is that his allows
      for removal all of the daemon presence tracking from NMObject.
      1f5b48a5
  24. 21 Oct, 2016 1 commit
  25. 17 Aug, 2016 1 commit
  26. 05 May, 2016 1 commit
  27. 22 Apr, 2016 1 commit
  28. 08 Apr, 2016 2 commits
  29. 05 Apr, 2016 1 commit
    • Thomas Haller's avatar
      build: disable deprecation checks for internal compilation · 9152dec9
      Thomas Haller authored
      For internal compilation we want to be able to use deprecated
      API without warnings.
      
      Define the version min/max macros to effectively disable deprecation
      warnings.
      
      However, don't do it via CFLAGS option in the makefiles, instead hack it
      to "nm-default.h". After all, *every* source file that is for internal
      compilation needs to include this header as first.
      9152dec9