1. 13 Mar, 2018 1 commit
  2. 12 Mar, 2018 1 commit
  3. 05 Mar, 2018 1 commit
  4. 21 Feb, 2018 1 commit
  5. 16 Feb, 2018 1 commit
  6. 14 Feb, 2018 1 commit
  7. 13 Feb, 2018 3 commits
  8. 10 Jan, 2018 3 commits
  9. 09 Jan, 2018 1 commit
  10. 08 Jan, 2018 1 commit
  11. 07 Jan, 2018 1 commit
  12. 04 Jan, 2018 3 commits
  13. 19 Dec, 2017 1 commit
  14. 14 Dec, 2017 1 commit
  15. 11 Dec, 2017 1 commit
  16. 28 Nov, 2017 1 commit
  17. 31 Oct, 2017 1 commit
  18. 16 Oct, 2017 1 commit
  19. 11 Oct, 2017 1 commit
  20. 09 Oct, 2017 1 commit
  21. 14 Sep, 2017 1 commit
    • Chun-wei Fan's avatar
      meson: Install items according to their relevance · a7a6449f
      Chun-wei Fan authored
      The m4 and bash completion items are usable and relevant
      depending on the host system's configuration.  So, we check for the
      presence of the programs that these items depend on, and only install
      them when those programs are found.
      
      For the Valgrind suppression files, we don't install them on Windows as
      Valgrind is currently not supported on Windows.
      
      Als fix the path where the GDB helpers are installed, as the path is
      incorrectly constructed.
      
      This will fix the "install" stage when building on Visual Studio at
      least as there are some post-install steps that are related to them,
      which will make use of these programs.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783270
      a7a6449f
  22. 11 Sep, 2017 2 commits
  23. 04 Sep, 2017 1 commit
  24. 19 Aug, 2017 1 commit
  25. 17 Aug, 2017 5 commits
    • Chun-wei Fan's avatar
      Meson: Set _WIN32_WINNT to 0x0601 (Windows 7) · 54aee1f6
      Chun-wei Fan authored
      We want to set _WIN32_WINNT so that functions will be properly found in
      the headers, to target the NT6.1+ (Windows 7+) APIs.
      
      Also improve the checks for if_nametoindex() and if_indextoname() on
      Windows as they are supported in Windows Vista+, but they have
      to be checked by linking against iphlpapi.lib (or -liphlpapi).  On other
      platforms, they are still checked as they were before.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783270
      54aee1f6
    • Chun-wei Fan's avatar
      meson/Windows: Check whether system PCRE is a static build · ea6ac5f7
      Chun-wei Fan authored
      Instead of hardcoding -DPCRE_STATIC into the CFLAGS of GLib, do the
      following on Windows only (since PCRE_STATIC only matters on Windows):
      
      -If there is no installed PCRE, use the included PCRE copy and
       enable -DPCRE_STATIC, as we did before.
      -If there is a installed PCRE, check whether the PCRE build is a static
       or DLL build by checking the linkage against pcre_free() with
       PCRE_STATIC defined works.  If it does, enable -DPCRE_STATIC.
      -On non-Windows builds, do not enable -DPCRE_STATIC
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783270
      ea6ac5f7
    • Chun-wei Fan's avatar
      Meson: Check for HAVE_GOOD_PRINTF · 72528938
      Chun-wei Fan authored
      The HAVE_GOOD_PRINTF config variable determines whether we are able to
      use the CRT-supplied *printf() functions directly, by determining whether
      the CRT-supplied vsnprintf() and snprintf() functions support C99 well
      enough.
      
      This means, we need to build the gnulib subdir as a static lib in GLib, and use
      the gnulib *printf() functions when:
      
      -We are on Windows
      -The CRT's vsnprintf() and snprintf() is not sufficiently C99-compliant.
      
      This will fix the problem when the *printf() functions cause a CRT
      abort() call on pre-2015 Visual Studio builds at least, and ensures that
      the Visual Studio 2015+ builds will pass the printf tests in GLib, since
      the *printf() in Visual Studio 2015/2017's CRT does not support the %n
      format specifier, nor the positional parameters (which requires
      different _*printf_p*() functions), as indicated by
      glib/tests/test-printf.c.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783270
      72528938
    • Chun-wei Fan's avatar
      meson: Install msvc_recommended_pragmas.h on Windows · 79b84ba3
      Chun-wei Fan authored
      Copy the msvc_recommended_pragmas.h helper header when we build for
      Windows, so that people developing/using GLib on Windows can make use
      of them in Visual Studio, so that unwanted compiler noise can be
      filtered out and code with potentially-problematic warnings can be
      attended to.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783270
      79b84ba3
    • Chun-wei Fan's avatar
      build: Use Meson's find_library() for MSVC builds as needed · 32d6a76b
      Chun-wei Fan authored
      Some of the dependencies' build systems for Visual Studio do not provide a
      pkg-config file upon build, so we use find_library() for them when the
      corresponding pkg-config files are not found during Visual Studio builds,
      so that one will not need to make up pkg-config files for them, which
      could be error-prone.  These .lib names match the names that are built
      with the officially supported build system that is used by their
      respective Visual Studio support.
      
      For ZLib, this will make gio-2.0.pc reflect on the zlib .lib based on
      what is found, or whether we use the fallback/bundled ZLib, when we
      don't have a pkg-config file for ZLib on MSVC.  We still need to depend
      on Meson to be updated to put the correct link argument for linking ZLib
      in the pkg-config case.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=783270
      32d6a76b
  26. 14 Aug, 2017 1 commit
    • Nirbheek Chauhan's avatar
      meson: Always define _GNU_SOURCE for pthread checks · 4c468690
      Nirbheek Chauhan authored
      Without this, GNU-specific symbols won't be defined and the compiler
      check will pass because GCC will assume that you know what you're
      doing since it doesn't know what the symbol prototype is and compiler
      checks aren't built with -Wall -Werror.
      
      This will then cause a build failure because the wrong prototype will
      be used.
      4c468690
  27. 10 Aug, 2017 2 commits
  28. 07 Aug, 2017 1 commit