1. 19 Nov, 2014 1 commit
    • Dan Winship's avatar
      libnm, libnm-util: move settings doc generation to libnm-core · c1448698
      Dan Winship authored
      Move the settings/plugins doc generation from libnm-util to
      libnm-core, since libnm-util isn't being updated for all new
      properties.
      
      With this commit, the keyfile and ifcfg-rh documentation is basically
      unchanged, except that deprecated properties are now gone, and new
      properties have been added, and the sections are in a different order.
      (generate-plugin-docs.pl just outputs the settings in Makefile order,
      and they were unsorted in libnm-util, but are sorted in libnm-core).
      
      The settings documentation used for nm-settings.5, the D-Bus API docs,
      and the nmcli help is changed a bit more at this point, and mostly for
      the worse, since the libnm-core setting properties don't match up with
      the D-Bus API as well as the libnm-util ones do. To be fixed...
      
      (I also removed the "plugins docs" line in each plugin docs comment
      block while moving them, since those blocks will be used for more than
      just plugins soon, and it's sort of obvious anyway.)
      c1448698
  2. 14 Nov, 2014 1 commit
    • Dan Winship's avatar
      docs: make the settings docs work from tarball builds · 16a9fc49
      Dan Winship authored
      docs/api/settings-spec.xml was accidentally not getting disted,
      because gtk-doc.make explicitly removes all DISTCLEANFILES from
      distdir. However, it doesn't actually make sense for the settings docs
      files to be in DISTCLEANFILES anyway; they were put there rather than
      CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't
      delete them and break things. But the right fix is to just make them
      only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever
      get deleted otherwise.
      
      Also adjust the build rules to ensure that the generated docs don't
      get rebuilt in tarball builds, since that can cause problems when
      building from a read-only source tree, etc.
      
      Meanwhile, in an unrelated but also fatal bug, configure.ac's check
      for if the generated docs were already present never got updated for
      the cli/src -> clients/cli move, and so even if we had been disting
      settings-spec.xml, configure would still think that the tarball didn't
      have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would
      be set false and none of the generated docs would get used.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=740035
      16a9fc49
  3. 07 Nov, 2014 3 commits
  4. 01 Oct, 2014 1 commit
  5. 18 Sep, 2014 1 commit
    • Dan Winship's avatar
      libnm: port to GDBus · 6793a32a
      Dan Winship authored
      Port libnm-core/libnm to GDBus.
      
      The NetworkManager daemon continues to use dbus-glib; the
      previously-added connection hash/variant conversion methods are now
      moved to NetworkManagerUtils (along with a few other utilities that
      are now only needed by the daemon code).
      6793a32a
  6. 01 Aug, 2014 1 commit
    • Dan Winship's avatar
      all: port everything to libnm · a7c4d53d
      Dan Winship authored
      Since the API has not changed at this point, this is mostly just a
      matter of updating Makefiles, and changing references to the library
      name in comments.
      
      NetworkManager cannot link to libnm due to the duplicated type/symbol
      names. So it links to libnm-core.la directly, which means that
      NetworkManager gets a separate copy of that code from libnm.so.
      Everything else links to libnm.
      a7c4d53d
  7. 30 Jul, 2014 1 commit
    • Dan Winship's avatar
      clients: reorganize source tree, put all the installed clients together · 3d25d704
      Dan Winship authored
      Create a new clients/ subdirectory at the top level, and move cli/ and
      tui/ into it, as well as nm-online.c (which was previously in test/,
      which made no sense).
      
      cli/ was split into two subdirectories, src/ and completion/. While
      this does simplify things (given that the completion file and the
      binary both need to be named "nmcli"), it bloats the source tree, and
      we can work around it by just renaming the completion file at install
      time. Then we can combine the two directories into one and just have
      it all under clients/cli/.
      3d25d704
  8. 15 Jul, 2014 1 commit
    • Dan Winship's avatar
      build: more srcdir!=builddir fixes · 30c74c60
      Dan Winship authored
      nm-version.h was getting disted, making srcdir!=builddir work for
      tarball builds, but not for git builds.
      
      Also, remove "-I${top_builddir}/include" from all Makefile.ams, since
      there's nothing generated in include/ any more.
      30c74c60
  9. 27 Jun, 2014 1 commit
  10. 19 Jun, 2014 1 commit
  11. 04 Jun, 2014 1 commit
  12. 23 Apr, 2014 1 commit
  13. 13 Feb, 2014 1 commit
    • Dan Winship's avatar
      libnm-util, libnm-glib: add versioned deprecation/availability macros · 9c4d86ee
      Dan Winship authored
      Add versioned NM_DEPRECATED_IN_* and NM_AVAILABLE_IN_* macros, and tag
      new/deprecated functions accordingly. (All currently-deprecated
      functions are assumed to have been deprecated in 0.9.10.)
      
      Add NM_VERSION_MIN_REQUIRED and NM_VERSION_MAX_ALLOWED macros which
      can be set to determine which versions will cause warnings.
      
      With the current settings, external consumers of the
      libnm-util/libnm-glib APIs will have MIN_REQUIRED and MAX_ALLOWED both
      set to NM_VERSION_0_9_8 by default, meaning they will get warnings
      about functions added in 0.9.10. NM internally sets
      NM_VERSION_MAX_ALLOWED to NM_VERSION_NEXT_STABLE to ensure that it is
      always allowed to use all APIs.
      9c4d86ee
  14. 22 Aug, 2013 1 commit
    • Dan Winship's avatar
      build: switch from $(INCLUDES) to $(AM_CPPFLAGS) to make automake happy · bfce3f7d
      Dan Winship authored
      Unfortunately, $(AM_CPPFLAGS) gets overridden by per-target _CPPFLAGS
      variables, which $(INCLUDES) did not, so this requires some additional
      changes.
      
      In most places, I have just gotten rid of the per-target _CPPFLAGS
      variables; in directories with a single target, the per-target
      variable is unnecessary, and in directories with multiple targets, the
      per-target variable is often undesirable, since it forces some files
      to be compiled twice, even though there ends up being no difference
      between the two files.
      bfce3f7d
  15. 31 Oct, 2012 1 commit
    • Colin Walters's avatar
      build: remove G_DISABLE_DEPRECATED · 59f2cd0f
      Colin Walters authored
      This functionality is (mostly) obsoleted by the newer
      GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED defines.  With
      this, your build doesn't all of a sudden blow up if we deprecate
      something in GLib - you have to explicitly opt-in to the newer
      version.
      
      G_DISABLE_DEPRECATED does still apply for macros and things that can't
      take __attribute__((deprecated)), but it's not really worth the pain
      and cargo culting around just for that.
      59f2cd0f
  16. 22 Feb, 2012 1 commit
  17. 09 Jan, 2012 1 commit
  18. 06 Jan, 2012 1 commit
  19. 12 Aug, 2011 1 commit
  20. 31 Mar, 2010 1 commit
  21. 25 Feb, 2010 1 commit