1. 28 Aug, 2018 1 commit
  2. 23 Aug, 2018 1 commit
  3. 07 Aug, 2018 2 commits
  4. 31 Jul, 2018 1 commit
  5. 27 Jun, 2018 1 commit
  6. 22 Jun, 2018 1 commit
  7. 12 Jun, 2018 2 commits
  8. 02 Jun, 2018 1 commit
    • Fabrice Fontaine's avatar
      Add RUST_TARGET variable · f0b76ab6
      Fabrice Fontaine authored
      Add RUST_TARGET environment variable through AC_ARG_VAR to allow the
      user to override the rust target name. Indeed, using $host when
      cross-compiling is not always the good option especially when vendor
      part of target is not set to unknown but to another value such as
      buildroot.
      Indeed, in this case aarch64-buildroot-linux-gnu won't be recognised as
      a valid target by rust/cargo.
      Signed-off-by: Fabrice Fontaine's avatarFabrice Fontaine <fontaine.fabrice@gmail.com>
      f0b76ab6
  9. 31 Mar, 2018 1 commit
  10. 17 Mar, 2018 1 commit
  11. 16 Mar, 2018 1 commit
  12. 27 Feb, 2018 2 commits
  13. 26 Feb, 2018 1 commit
  14. 23 Feb, 2018 3 commits
  15. 22 Feb, 2018 1 commit
  16. 19 Feb, 2018 1 commit
  17. 16 Feb, 2018 1 commit
  18. 13 Feb, 2018 1 commit
  19. 08 Feb, 2018 1 commit
  20. 02 Feb, 2018 1 commit
  21. 23 Jan, 2018 1 commit
  22. 12 Jan, 2018 1 commit
  23. 08 Jan, 2018 1 commit
  24. 14 Dec, 2017 1 commit
  25. 08 Dec, 2017 1 commit
  26. 06 Dec, 2017 1 commit
  27. 30 Nov, 2017 1 commit
  28. 16 Nov, 2017 1 commit
    • David Michael's avatar
      Support cross-compiling with Rust · fd9541ad
      David Michael authored
      The primary change here is to add the --target=$(host) option to
      the cargo build command, so the Rust components are compiled for
      the target host system specified by the configure command.  The
      cargo target subdirectory also needed to be prefixed with the host
      triplet for cross-compiling.
      
      Some of the crates' build scripts require cross-pkg-config settings
      in the environment, so they are set for the cargo build command.
      
      It's worth noting that Rust targets are limited to built-in values
      by default, so the --host value given to configure may not be
      supported.  Built in targets can be found by listing the directory
      src/librustc_back/target in the rustc source.  When building with
      an unsupported target, the user will have to write a target JSON
      definition file and set the environment variable RUST_TARGET_PATH
      to its directory (as with building any Rust project).
      
      This also sneaks in prefixing the Rust library recipe line with a
      "+" character to pass the GNU Make jobserver environment and file
      descriptors, which cargo supports to act as a jobserver client.
      fd9541ad
  29. 03 Oct, 2017 1 commit
  30. 02 Sep, 2017 1 commit
  31. 09 Aug, 2017 1 commit
    • Chun-wei Fan's avatar
      build: Check for PangoFT2/FontConfig availability · 46c8688a
      Chun-wei Fan authored
      On Windows the GTK+ stack does not hard depend on PangoFT2 (thus
      Fontconfig--GTK+ uses PangoWin32 to do the Font discovery and
      configuration stuff by default, unless one uses an envvar to force
      PangoFT2 usage), unlike *NIX platforms, so we need to check for
      it by doing:
      
      -On Windows, enable the test code that uses PangoFT2/FontConfig if
       PangoFT2 and FontConfig is found during configure.  On Visual Studio
       builds, this is set to be disabled in config.h.win32(.in), and can be
       manually enabled by uncommenting #define HAVE_PANGOFT2 1 in
       config.h.win32 prior to the build (or rebuild).  This continues to have
       FontConfig and PangoFT2 to act as an optional dependency.
      
      -On non-Windows platforms, make PangoFT2 and FontConfig a hard dependency,
       which is what the current code assumes.
      
      We might probably need to make the custom TTF load via PangoWin32 and/or
      the native Windows API to run the tests when PangoFT2 and FontConfig are
      not found on Windows.
      
      Also bump the Pango dependency to 1.38 as the test code uses API that is
      introduced in 1.38.x.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=779405
      46c8688a
  32. 07 Aug, 2017 1 commit
  33. 03 Mar, 2017 1 commit
  34. 23 Feb, 2017 1 commit
    • Chun-wei Fan's avatar
      Visual Studio builds: Move projects to win32/ · 1bfa2d7b
      Chun-wei Fan authored
      Move the projects to win32/ from build/win32/, so that one will need to go down
      one less level down the tree to reach the project files, and will allow the
      autotools modules (Makefile.msvcproj, Makefile-newvs.am,
      Makefile.msvc-introspection) to be in sync with the ones in GLib and G-I master.
      
      This also makes the support of Visual Studio 2017 complete by allowing it in the
      NMake Makefiles, which is a must for this package since NMake Makefiles are used
      to build the Rust bits on Visual Studio, as well as for introspection builds.
      1bfa2d7b
  35. 15 Feb, 2017 1 commit
    • Chun-wei Fan's avatar
      Visual Studio builds: Support Visual Studio 2017 · bb4c37bf
      Chun-wei Fan authored
      Update the autotools scripts so that we can support Visual Studio 2017 by
      copying the 2013 projects and update items as necessary to produce the
      2017 projects
      
      Note that the toolset version string format changed for Visual Studio 2017, so allow
      one to use a custom toolset version string, otherwise a default toolset version string
      string will be generated as it was before.
      
      Note also that Visual Studio 2017 aims to be compatible with Visual Studio 2015 on the
      CRT level, so it should be possible to use 2017-built binaries with 2015-built binaries.
      bb4c37bf