1. 30 May, 2019 1 commit
  2. 22 Apr, 2019 1 commit
    • Michael Gratton's avatar
      build: Remove */.gitignore files · 6b61395c
      Michael Gratton authored
      Since out-of-source-tree builds are now used after switching to meson,
      we don't need .gitignore files in the source directories to ignore
      build artifacts.
      This fixes build errors when doing a meson build after an autotools
      build, because generated files such as gio/xdp-dbus.c won't show up in
      a `git status`, or be removed by a `git clean -f`, and so it won't be
      obvious that such files need to be removed for the meson build to
  3. 15 Jan, 2019 1 commit
    • Philip Withnall's avatar
      build: Drop autotools support · b3efef5b
      Philip Withnall authored
      So long, and thanks for everything. We’re a Meson-only shop now.
      glib-2-58 will remain the last stable GLib release series which is
      buildable using autotools.
      We continue to install autoconf macros for autotools-using projects
      which depend on GLib; they are stable API.
      Signed-off-by: Philip Withnall's avatarPhilip Withnall <withnall@endlessm.com>
  4. 10 Dec, 2018 2 commits
  5. 25 Nov, 2018 1 commit
  6. 22 Oct, 2018 1 commit
  7. 04 Sep, 2018 1 commit
  8. 06 Jun, 2018 1 commit
  9. 17 May, 2018 1 commit
  10. 09 May, 2018 1 commit
  11. 28 Mar, 2018 1 commit
  12. 04 Jan, 2018 2 commits
  13. 02 Nov, 2017 1 commit
  14. 06 Oct, 2017 1 commit
  15. 13 Jul, 2017 4 commits
  16. 10 Jul, 2017 1 commit
  17. 24 May, 2017 1 commit
  18. 09 May, 2017 2 commits
  19. 06 Apr, 2017 1 commit
  20. 23 Mar, 2017 1 commit
  21. 22 Nov, 2016 1 commit
  22. 15 Feb, 2014 2 commits
    • Allison Karlitskaya's avatar
      win32: fixup lib.exe invocation · 7cbff954
      Allison Karlitskaya authored
      We have a configure.ac check for lib.exe that attempts to enable
      creation of .lib files for our 5 public libraries.  That has been broken
      for a long time for two reasons:
       1) the Makefiles hardcode 'lib' instead of 'lib.exe'
       2) we dropped generation of .def files quite some time ago (except for
          in gthread where we have the two-symbol file under version control)
      Add new rules for creating .def files from dumpbin.exe (which you should
      have if you have lib.exe) and fix the .lib rules to use lib.exe.
      Add a bit of $(AM_V_GEN) all around, as well.
    • Matthias Clasen's avatar
      docs: let go of &ast; · bc6ee788
      Matthias Clasen authored
      Since we are no longer using sgml mode, using /&ast; &ast;/ to
      escape block comments inside examples does not work anymore.
      Switch to using line comments with //
  23. 08 Feb, 2014 1 commit
  24. 06 Feb, 2014 2 commits
  25. 01 Feb, 2014 3 commits
  26. 31 Jan, 2014 2 commits
  27. 20 Nov, 2013 3 commits
    • Dan Winship's avatar
      Replace #ifdef HAVE_UNISTD_H checks with #ifdef G_OS_UNIX · 158dde05
      Dan Winship authored
      In Windows development environments that have it, <unistd.h> is mostly
      just a wrapper around several other native headers (in particular,
      <io.h>, which contains read(), close(), etc, and <process.h>, which
      contains getpid()). But given that some Windows dev environments don't
      have <unistd.h>, everything that uses those functions on Windows
      already needed to include the correct Windows header as well, and so
      there is never any point to including <unistd.h> on Windows.
      Also, remove some <unistd.h> includes (and a few others) that were
      unnecessary even on unix.
    • Dan Winship's avatar
      Remove alleged support for last-millennium Unixes · 7f5b2901
      Dan Winship authored
      Remove workarounds for NeXTStep (last released in 1995), SunOS (1994),
      HP-UX 9.x (1992) and 10.x (1995), OSF/1 / Digital UNIX / Tru64 UNIX
      4.x (1999), and AIX 4.x (1999).
      HP-UX 11 implements dlopen(), so dropping support for earlier versions
      also lets us remove the HP-UX-specific gmodule-dld.
    • Dan Winship's avatar
      Remove alleged support for BeOS · 51a917bc
      Dan Winship authored
      Since the initial addition of BeOS support in 1999, there has only
      been one update to it (in 2005, and it wasn't even very big). GLib is
      known to not currently build on Haiku (or presumably actual BeOS)
      without additional patching, and the fact that there isn't a single
      G_OS_BEOS check in gio/ is suspicious.
      Additionally, other than the GModule implementation, all of the
      existing G_OS_BEOS checks are either (a) "G_OS_UNIX || G_OS_BEOS", or
      (b) random minor POSIXy tweaks (include this header file rather than
      that one, etc), suggesting that if we were going to support Haiku, it
      would probably be simpler to treat it as a special kind of G_OS_UNIX
      (as we do with Mac OS X) rather than as its own completely different
      So, kill G_OS_BEOS.