1. 28 Oct, 2019 2 commits
  2. 26 Oct, 2019 1 commit
  3. 25 Oct, 2019 1 commit
  4. 24 Oct, 2019 1 commit
  5. 19 Oct, 2019 2 commits
    • Jehan's avatar
      app, libgimp*: (meson) fix all the generated `*-enums.c`. · b8d8424a
      Jehan authored
      More of the files were wrong, or at least not absolutely identical to
      the files generated by the autotools. I am not doing any code change
      other than trying to make both build systems produce identical files
      (except for slight differences on 2 files not worth the effort) even
      though maybe some things can be improved (especially on the include
      list). Maybe to be improved later.
      
      Also fixing 2 of the previously autotools-generated files because of
      space typos which should have been committed earlier.
      
      Finally it is to be noted that there is no logics to copy the generated
      files back to the source directory in the meson rules. I am not sure
      anyway this is really worth it and maybe we should just stop tracking
      these generated files eventually.
      b8d8424a
    • Jehan's avatar
      libgimpwidgets: (meson) fix gimpwidgetsenums.c generation. · 5d79fba8
      Jehan authored
      Noticed by Massimo.
      gimp_type_set_translation_domain() calls were missing.
      Also make so that the output is exactly similar (even whitespaces) as
      the autotools one, making it easier to diff, hence maintain.
      5d79fba8
  6. 14 Oct, 2019 1 commit
    • Jehan's avatar
      meson: add a big fat "experimental" warning at end of meson configure. · fb0ea136
      Jehan authored
      It should be clear that the autotools build is still the officially
      mandated one for all finale builds (i.e. packaging). Our meson builds
      still have bugs (some we know of and are trying to fix, others that we
      will probably discover soon) so packagers should be well aware that they
      should not use meson (though we highly encourage it for developers so
      that bugs can be found).
      
      Adding this warning as someone was asking on a bug report whether
      autotools were still being supported (while it's the opposite: meson is
      still not officially stable and autotools is still our main build
      system).
      fb0ea136
  7. 12 Oct, 2019 2 commits
    • Jehan's avatar
      meson: add an `install-icons` meson target. · fca64f5f
      Jehan authored
      We want to be able to install icons only in a quick command when
      testing/developing.
      Also I realize that Legacy icons are not even installed with meson
      build, which is bad! Even though legacy, we want to keep them (at least
      for the time being), just as we do with autotools.
      fca64f5f
    • Jehan's avatar
      meson: add a special target `install-libgimp*` for all libgimp*. · 1046430d
      Jehan authored
      For instance, we can install libgimpwidgets with:
      > ninja install-libgimpwidgets
      
      A special target had been previously added only for libgimp.
      1046430d
  8. 21 Sep, 2019 5 commits
    • luzpaz's avatar
      Fix various typos · 44d10e45
      luzpaz authored
      Found via `codespell` (v1.17.0.dev0)
      44d10e45
    • Jehan's avatar
      meson: minor formatting fixes. · 7806021a
      Jehan authored
      7806021a
    • Jehan's avatar
      meson: fix relocatable-bundle feature and mypaint-brushes dependency. · 738dab0f
      Jehan authored
      It must not be a boolean but a `feature` option, with `auto` by default.
      `auto` value mean enabled for macOS and Win32, and disabled for other
      cases. This default logics disappeared in the meson build.
      
      Also the mypaint-brushes package is a mandatory dependency, which must
      always be checked. Absence is fatale.
      Finally properly set the MYPAINT_BRUSHES_DIR macro depending on the
      proper relocatable case.
      738dab0f
    • Jehan's avatar
      meson: fix several checks. · b327e0ff
      Jehan authored
      For pango and libbacktrace, we only need a compilation/link test. No run
      is needed.
      As for the exchndl (Windows only), this is an optional feature, hence
      should not be a fatale check.
      b327e0ff
    • Jehan's avatar
      meson: fix glib-networking check when cross-compiling. · b8c34c41
      Jehan authored
      3 cases are possible:
      - in native build, the test must succeed and is a fatale error.
      - in cross-compilation, if no `exe_wrapper` binaries were set in the
        toolchain file, we just bypass the check, yet still output a warning
        so that packagers won't forget to add the dependency.
      - in cross-compilation with an `exe_wrapper` (for instance `wine` for a
        win32 target), we run the check. Even if it fails, we don't make it a
        fatale error then simply output a warning as cross-platform execution
        are not always reliable anyway.
      b8c34c41
  9. 20 Sep, 2019 1 commit
  10. 12 Sep, 2019 1 commit
  11. 11 Sep, 2019 4 commits