1. 07 Jun, 2016 1 commit
    • Chun-wei Fan's avatar
      config.h.win32.in: Always define HAVE_LONG_LONG · 9198f19d
      Chun-wei Fan authored
      Visual Studio actually supports long long types, but HAVE_LONG_LONG is
      undefined for Visual Studio builds, likely due to issues in previous
      gnulib code for printf functionality, that was bundled with GLib.
      
      Since gnulib has much better support with Visual Studio nowadays (which we
      updated the related code to last October), and HAVE_LONG_LONG being undefined
      actually causes issues in Visual Studio builds, which was demonstrated with
      the type-test test program in tests/, we should always define HAVE_LONG_LONG
      in config.h.win32.in.
      
      Thanks to Paolo Borelli for the heads up on the issue.
      9198f19d
  2. 02 Dec, 2015 1 commit
  3. 01 Oct, 2015 1 commit
  4. 21 Jul, 2015 1 commit
    • Chun-wei Fan's avatar
      config.h.win32.in: Clean Up and Update · 53d487e3
      Chun-wei Fan authored
      Merge the parts that has things to do with stdint.h and inttypes.h with
      the !_MSC_VER portions, and add initial support for Visual Studio 2015,
      which added support for C99 snprintf() and vsnprintf().
      
      Not too sure about the !_MSC_VER for C99 snprintf() and vsnprintf(), but
      since this file is mainly for Visual Studio builds, anyways...
      53d487e3
  5. 07 Jan, 2015 1 commit
    • Chun-wei Fan's avatar
      Win32: Update Pre-configured Config Headers · 1632d571
      Chun-wei Fan authored
      Update config.h.win32.in and glibconfig.h.win32.in so that they will be
      in-line with the ones that are produced with configure.ac, for use on
      Windows builds.
      
      Thanks to Philip Withnall for pointing out the changes needed to update
      glibconfig.h.win32.in in bug 727829.
      1632d571
  6. 23 May, 2014 1 commit
    • Chun-wei Fan's avatar
      config.h.win32.in: Define _WIN32_WINNT Conditionally · e3db9632
      Chun-wei Fan authored
      This is done so that _WIN32_WINNT may be overridden in the project files,
      if needed, so that one can access the Vista+ (or so) Windows APIs easier
      by using "preprocessor defines" (or so) in the Visual C++ project files.
      e3db9632
  7. 19 May, 2014 1 commit
  8. 12 Mar, 2014 1 commit
  9. 22 Dec, 2013 1 commit
  10. 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.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710519
      158dde05
    • Dan Winship's avatar
      Require POSIX.1 (1990) compliance on unix · 3981cddb
      Dan Winship authored
      Assume unix platforms support the original POSIX.1 standard.
      Specifically, assume that if G_OS_UNIX, then we have chown(),
      getcwd(), getgrgid(), getpwuid(), link(), <grp.h>, <pwd.h>,
      <sys/types.h>, <sys/uio.h>, <sys/wait.h>, and <unistd.h>.
      
      Additionally, since all versions of Windows that we care about also
      have <sys/types.h>, we can remove HAVE_SYS_TYPES_H checks everywhere.
      
      Also remove one include of <sys/times.h>, and the corresponding
      configure check, since the include is not currently needed (and may
      always have just been a typo for <sys/time.h>).
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710519
      3981cddb
    • Dan Winship's avatar
      Require C90 compliance · 6e4a7fca
      Dan Winship authored
      Assume all supported platforms implement C90, and therefore they
      (correctly) implement atexit(), memmove(), setlocale(), strerror(),
      and vprintf(), and have <float.h> and <limits.h>.
      
      (Also remove the configure check testing that "do ... while (0)" works
      correctly; the non-do/while-based version of G_STMT_START and
      G_STMT_END was removed years ago, but the check remained. Also, remove
      some checks that configure.ac claimed were needed for libcharset, but
      aren't actually used.)
      
      Note that removing the g_memmove() function is not an ABI break even
      on systems where g_memmove() was previously not a macro, because it
      was never marked GLIB_AVAILABLE_IN_ALL or listed in glib.symbols, so
      it would have been glib-internal since 2004.
      
      https://bugzilla.gnome.org/show_bug.cgi?id=710519
      6e4a7fca
  11. 21 Aug, 2013 1 commit
    • Chun-wei Fan's avatar
      Update config.h.win32.in · e05abaed
      Chun-wei Fan authored
      Make entries more in sync with the items checked with autotools, and
      provide a MinGW declaration for _GLIB_EXTERN, taken from configure.ac.
      e05abaed
  12. 16 Aug, 2013 2 commits
  13. 27 May, 2013 1 commit
    • Chun-wei Fan's avatar
      Update config.h.win32(.in) · 80985d1c
      Chun-wei Fan authored
      Make the entries of config.h.win32(.in) consistent with the entries
      that are generated from the autotools build (config.h.in).
      80985d1c
  14. 01 Mar, 2013 1 commit
    • Chun-wei Fan's avatar
      Update config.h.win32.in · 872d3634
      Chun-wei Fan authored
      Add entry for __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, to better reflect the
      entries of items in config.h.in.  We are not currently defining this here
      as the pre-configured config.h.win32.in is primarily meant for Visual
      Studio builds of GLib-the MinGW/GCC/Clang builds of GLib will normally
      use the autotools builds, which should give the correct config.h entries
      upon running ./configure.
      872d3634
  15. 15 Jan, 2013 1 commit
    • Chun-wei Fan's avatar
      Bug 688681: Stop using .def files in Visual Studio builds · 4ba56f36
      Chun-wei Fan authored
      Since we are now starting to use __declspec (dllexport) to export the
      public functions during the build of the GLib DLLs (i.e. to generate the
      .lib files), we don't want to generate the .def files from the .symbols
      files as we did before for a long time.
      
      This removes from the projects the custom build steps to generate the
      various .def files
      
      This will also update the pre-configured config.h(.win32.in) to define
      _GLIB_EXTERN appropriately as __declspec (dllexport), as well as making its
      entries reflect config.h.in more closely.
      4ba56f36
  16. 19 Nov, 2012 1 commit
    • Chun-wei Fan's avatar
      Update config.h.win32.in · 39150f90
      Chun-wei Fan authored
      Make its entries correspond to the entries in config.h.in, and use
      _strnicmp for strncasecmp on Visual C++.
      39150f90
  17. 26 Sep, 2012 1 commit
  18. 19 Mar, 2012 1 commit
    • Chun-wei Fan's avatar
      Update config.h.win32(.in) · 19089104
      Chun-wei Fan authored
      Make it more like the one that is generated by autotools.
      
      It is true that Visual C++ has sig_atomic_t, at least for Visual C++ 2008
      and later, but this is currently only used for UNIX builds of GLib, as a
      point of note here.
      19089104
  19. 08 Mar, 2012 1 commit
  20. 08 Feb, 2012 2 commits
  21. 30 Dec, 2011 1 commit
    • Chun-wei Fan's avatar
      config.h.win32.in: Cleanups · a2e1541c
      Chun-wei Fan authored
      -Make the contents of the preconfigured config.h.win32(.in) more like the
       contents of config.h.in
      -Correct the sizing of void* on x64 platforms (which should be 8, unlike
       4 on x86-32 platforms)
      a2e1541c
  22. 06 Oct, 2011 1 commit
  23. 30 Sep, 2011 1 commit
  24. 22 Aug, 2011 1 commit
    • Chun-wei Fan's avatar
      Update config.h.win32.in · 09a322c8
      Chun-wei Fan authored
      Make the pre-configured config.h(.win32.in) for Windows more like the
      config.h that would be produced during ./configure on Windows systems.
      09a322c8
  25. 11 Aug, 2011 1 commit
    • Chun-wei Fan's avatar
      Bug 652827: Update config.h.win32.in · 77a10fea
      Chun-wei Fan authored
      Add check macro for HAVE_WIN32_BUILTINS_FOR_ATOMIC_OPERATIONS, as it is
      now required for MSVC builds of glib/gatomic.c GLib 2.29.15+.
      
      It is true that the MinGW cross-compiler on Linux systems will have
      HAVE_GCC_BUILTINS_FOR_ATOMIC_OPERATIONS and
      HAVE_WIN32_BUILTINS_FOR_ATOMIC_OPERATIONS defined during the completion
      of ./configure, but since this file is primarily meant for people
      compiling -on- Windows (and that the "native" Windows MinGW would neither
      ./configure to define HAVE_GCC_BUILTINS_FOR_ATOMIC_OPERATIONS and
      HAVE_WIN32_BUILTINS_FOR_ATOMIC_OPERATIONS), this file will be updated as
      it is for now at least until the situation for "native" Windows MinGW
      change. (please see Bug 652827 regarding this paragraph)
      77a10fea
  26. 22 Jun, 2011 1 commit
  27. 07 Jun, 2011 1 commit
  28. 10 Mar, 2011 1 commit
  29. 13 Jul, 2010 1 commit
  30. 19 May, 2010 1 commit
  31. 22 Mar, 2010 1 commit
  32. 14 Dec, 2009 2 commits
  33. 30 May, 2009 1 commit
  34. 15 Sep, 2008 1 commit
  35. 27 Aug, 2008 1 commit
    • Tor Lillqvist's avatar
      Should not define HAVE_DIRENT_H when compiling with MSVC, as the only file · 194493f3
      Tor Lillqvist authored
      2008-08-27  Tor Lillqvist  <tml@novell.com>
      
      	* config.h.win32.in: Should not define HAVE_DIRENT_H when
      	compiling with MSVC, as the only file which checks HAVE_DIRENT_H
      	is gdir.c, and that includes the dirent.h and wdirent.c from
      	build/win32/dirent explicitly anyway when being compiled with
      	MSVC.
      
      
      svn path=/trunk/; revision=7403
      194493f3