1. 25 Jul, 2019 2 commits
  2. 22 Feb, 2019 1 commit
  3. 29 Jun, 2018 1 commit
  4. 04 Apr, 2018 1 commit
    • Thomas Haller's avatar
      examples: add python utils for examples · d14b9b82
      Thomas Haller authored
      We need common operations from the python scripts.
      For example, to print the boot-time.
      Move such utils to a separate nmex.py file ("ex" for
      example). This file should contain helper functions that
      are pure python (or, if the have requirements, load them
      only on demand, so that examples that need those have
      additional dependencies). It should also be simple to extract
      individual helpers from nmex, so that the user can take an
      example, merge parts of nmex.py in, and modify it to his needs.
  5. 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.
    • 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".
  6. 10 Jan, 2018 1 commit
  7. 05 Dec, 2017 1 commit
  8. 06 Nov, 2017 1 commit
  9. 06 May, 2017 2 commits
  10. 29 Mar, 2017 2 commits
  11. 17 Mar, 2017 1 commit
  12. 09 Jan, 2017 1 commit
  13. 24 Nov, 2016 1 commit
    • Thomas Haller's avatar
      build: avoid some uses of BUILT_SOURCES in Makefile.am · ec4a1b75
      Thomas Haller authored
      BUILT_SOURCES only matters during `make all`, `make check`
      and `make install`.
      It would be nice to be able to build every target specifically
      from an empty git-tree.
      Drop the use of BUILT_SOURCES where we already have the explicit
      dependencies declared.
  14. 21 Oct, 2016 3 commits