1. 06 Jan, 2014 3 commits
    • Chun-wei Fan's avatar
      Fix GLib MSVC Project · eb7ef594
      Chun-wei Fan authored
      The glib/gthread-win32.c was accidently removed from the last commit, sorry
    • Chun-wei Fan's avatar
      Tidy Up the glib MSVC Project · 940b3c22
      Chun-wei Fan authored
      Move the per-source define/undefine cflags into the property sheets, and
      apply the cflags for the bundled PCRE sources to the PCRE sources only
    • Chun-wei Fan's avatar
      Drop the testglib MSVC Projects · 16c41f0c
      Chun-wei Fan authored
      There are many test programs that are shipped with GLib, and this project
      is a one-to-one project, which does not make sense to keep as various test
      programs may have different CFLAGS, etc, which will require different build
  2. 02 Jan, 2014 1 commit
  3. 27 Dec, 2013 3 commits
    • Chun-wei Fan's avatar
      Visual Studio Projects: Cleanup Property Sheets · ddc29a90
      Chun-wei Fan authored
      Make the projects include a single property sheet as necessary, which will
      in turn include the other property sheet(s) as needed, so that we can avoid
      warnings where we include the same property sheets twice in a single
      Also make the copying of pre-configured headers into custom build rules so
      that they can be removed upon the clean command from the IDE and that they
      can be re-copied if their counterpart *.h.win32 are updated.
    • Chun-wei Fan's avatar
      Visual Studio Projects: Use Unix Line Endings · d01a0756
      Chun-wei Fan authored
      ...where possible, to make application of patches easier in the future.
      The README.txt's and the .sln files are still in Windows/DOS line endings
      as they need to be so.
    • Chun-wei Fan's avatar
      Visual Studio Property Sheets: Use Unix Line Endings · c488aa67
      Chun-wei Fan authored
      This makes it easier to apply patches in the future.
  4. 11 Dec, 2013 1 commit
  5. 02 Dec, 2013 1 commit
  6. 05 Sep, 2013 1 commit
    • Chun-wei Fan's avatar
      Visual C++ Builds: Fix "install" Projects · 52251a52
      Chun-wei Fan authored
      Due to the split up of the property sheets, the install projects did not
      have info on the Intermediate and Output Paths, which caused confusing
      messages from Visual Studio to show up upon completing build+"install" and
      closing Visual Studio on whether to reload the install project, at least on
      Visual Studio 2008.
      Include the property sheet which defines these properties to fix this.
  7. 21 Aug, 2013 6 commits
    • Chun-wei Fan's avatar
      Fix typo in last commit · 2ff85ca4
      Chun-wei Fan authored
      The gio.vcxprojin and glib.vcxprojin were including .vsprops property
      sheets, but it should have been .props instead.
    • Chun-wei Fan's avatar
      MSVC 2010 Project Files: Split up the Property Sheets · 113793a4
      Chun-wei Fan authored
      Like the Visual Studio 2008 project files, split up the property sheets
      so to ease maintenace, and to prepare to use autotools to fill in the
      header entries to "install".
      Put some of the items that are frequently repeated in the projects as well,
      also to simplify maintenance.
      Also, update the autotools files to automate the upgrade of Visual Studio
      2010 project as we now have multiple property sheets to copy and process.
    • Chun-wei Fan's avatar
      MSVC 2008 Projects: Split the Property Sheets · 3c4ee831
      Chun-wei Fan authored
      Split the property sheet into four sheets, to make maintainance of the
      build files easier, and also to prepare for using autotools to fill in
      the parts for the "installation" of headers.
      Also put more of the items that are repeated in the projects into the
      property sheets, also to improve ease of maintenance.
      Updates to the Visual Studio 2010 projects will come later, as the script
      to update them to Visual Studio 2012 must also be taken into account during'
      the process.
    • Chun-wei Fan's avatar
      GLib MSVC Projects: Consolidate PCRE items · 716ec71e
      Chun-wei Fan authored
      Move the definitions of macros used to build PCRE that ships with GLib into
      the property sheets, so that it can be easier to maintain
    • Chun-wei Fan's avatar
      GIO MSVC Projects: Drop Unneeded Defines · 18f498c3
      Chun-wei Fan authored
      GIO_MODULE_DIR is dynamically constructed on Windows, so we don't really
      need to define it here.
    • Chun-wei Fan's avatar
      GIO MSVC Project: Link to iphlpapi.lib · 7145f069
      Chun-wei Fan authored
      This is needed for GetAdaptersAddresses()[1], which was used to implement
      if_nametoindex on Windows, notably on Windows XP, in commit 01156b12.
      if_nametoindex and if_indextoname, as noted in config.h.win32(.in), is
      available with Windows Vista and later, so when we eventually drop
      support for Windows XP, we can call them directly, and these functions
      also reside in the same iphlpapi.lib
      [1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365915%28v=vs.85%29.aspx
  8. 17 Jul, 2013 2 commits
  9. 20 Jun, 2013 2 commits
    • Chun-wei Fan's avatar
      Add MSVC Projects for Utility Programs · 97b82d8d
      Chun-wei Fan authored
      Build and "install" the gio-querymodules and gdbus utility programs so that
      the Visual Studio builds of GLib is more comprehensive.  The Python scripts
      for the GDBus codegen will be added to "installation" later.
    • Chun-wei Fan's avatar
      Update Visual Studio Projects · ffaf57b9
      Chun-wei Fan authored
      Make all projects settings use the MultiByte character set when building
      GLib to improve consistency.
  10. 28 May, 2013 1 commit
  11. 27 May, 2013 2 commits
    • Chun-wei Fan's avatar
      Fix the GObject Visual Studio Projects · 0d55c4aa
      Chun-wei Fan authored
      Update G_LOG_DOMAIN to be "GLib-GObject" so that we are consistent with
      the autotools builds, and that tests expecting the log domain to be
      "GLib-GObject" would not fail.
    • Chun-wei Fan's avatar
      Fix the GLib Visual Studio Projects · 524470d8
      Chun-wei Fan authored
      Define the G_LOG_DOMAIN of the GLib DLL as "GLib", because:
      -This makes it consistent with the autotools builds
      -Some tests expect the log domain to be "GLib"
  12. 18 Mar, 2013 1 commit
  13. 19 Feb, 2013 1 commit
  14. 22 Jan, 2013 1 commit
  15. 19 Jan, 2013 3 commits
    • Chun-wei Fan's avatar
      Update Visual C++ 2010 property sheet · ca58dae2
      Chun-wei Fan authored
      Left out some items to purge in the last commit.  Sorry :|
    • Chun-wei Fan's avatar
      Clean up Visual C++ property sheets · 6c7539fe
      Chun-wei Fan authored
      We no longer need entries to generate the .def files in the property sheets
      as we are now doing __declspec (dllexport) to export all the needed
      symbols.  So, purge these items from the property sheets since they are no
      longer used.
    • Chun-wei Fan's avatar
      Bug 688681: Stop using the .def file for GThread Visual C++ builds · bdb7c2d9
      Chun-wei Fan authored
      We should also stop using gthread/gthread.def file as well, since we
      also use __declspec (dllexport) for the two (deprecated) functions there
      since commit f8756694.
      This should also silence some linker warnings in x64 builds.
      Also get rid of the references to the .symbols files in the
      .vcxproj.filters(in) in the various Visual C++ 2010 projects
  16. 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.
  17. 18 Dec, 2012 1 commit
  18. 14 Dec, 2012 1 commit
  19. 22 Nov, 2012 2 commits
    • Chun-wei Fan's avatar
    • Chun-wei Fan's avatar
      Add autotools scripts to create VS2012 projects · 76cecf06
      Chun-wei Fan authored
      As the project file format for Visual Studio 2012 is only slightly
      different from Visual Studio 2010 projects, we can provide support for
      building GLib (and other projects) with Visual Studio 2012 with relatively
      little effort.  This might change when we eventually get GLib to work with
      the Windows 8 (Modern UI/formerly Metro) APIs, but this will suffice for
      the time being for people needing to build GLib with Visual Studio 2012.
      Basically all that needs to be done at 'make dist' is:
      -Copy the .sln/.props/README.txt/.vcxproj files and replace the VS2010
       stuff with VS2012 stuff
      -Copy the .vcxproj.filters as is
  20. 05 Nov, 2012 1 commit
    • Chun-wei Fan's avatar
      Visual C++ 2010 projects: Prepare support for VS2012 · c5b9a47f
      Chun-wei Fan authored
      Add the PlatformToolset tag to the project configs so that we can use add a
      simple script later to the autotools files to copy the projects and change
      the value (v100 -> v110) of that tag (and other simple changes) in order
      that we can quickly provide and maintain support for Visual Studio 2012
      with minimal effort.
      Note that at the moment GLib does not yet support the API/SDK requirements
      for Windows 8 Modern UI (formerly known as Metro), but this paves the very
      initial step.
  21. 26 Sep, 2012 1 commit
  22. 30 Aug, 2012 1 commit
  23. 20 Jun, 2012 1 commit
  24. 18 Jun, 2012 1 commit
  25. 02 May, 2012 1 commit
    • Chun-wei Fan's avatar
      Fix GIO/GObject Visual C++ projects · 874355de
      Chun-wei Fan authored
      -Make up for the missed DLL_EXPORT-it's actually needed for all GLib DLL
       builds, omitting this caused problems to surface due to recent works to
       make GDBus work on Windows.
      -Also use the FFI_BULIDING macro for GObject builds as the suggessted
       workaround for using static LibFFI builds (as we do now)-please see
       ffi.h(.in). This will fix the build of GObject against LibFFI 3.0.11,
       but it is probable that this will change at some point for LibFFI.