1. 30 Jun, 2020 2 commits
    • Chun-wei Fan's avatar
      NMake Makefiles: Fix previous commit · 60084786
      Chun-wei Fan authored
      We should also account for Visual Studio 2015 when we use 'USE_MESON_LIBS' with
      'USE_COMPAT_LIBS' as well...
      60084786
    • Chun-wei Fan's avatar
      NMake Makefiles: Apply toolset version for Meson-built deps · ebb5906f
      Chun-wei Fan authored
      As the Meson build files for Visual Studio apply the toolset version in the
      .lib filenames by default, apply the toolset version in the Meson-built -mm
      .lib files that we link in, just as we did when we we link in the -mm .lib
      files that was built with NMake, by default.
      
      The option 'USE_COMPAT_LIBS' will also mean that we will use the former
      behavior when we link in the Meson-built -mm .lib's, just as we did when we
      link in the NMake-built -mm .lib's.
      ebb5906f
  2. 29 Jun, 2020 4 commits
    • Kjell Ahlstedt's avatar
      doc/reference/: Update for Doxygen >= 1.8.16 · 855938b8
      Kjell Ahlstedt authored
      * doc/reference/meson.build: Doxygen 1.8.16 and later does not store
      tag file names in the html files. This requires changes in meson.build
      and in doc-install.pl (in mm-common). Otherwise references to other modules
      won't be updated in the html files when they are installed.
      * doc/reference/Doxyfile.in: Remove PERL_PATH and MSCGEN_PATH.
      Doxygen since version 1.8.0 does not use them.
      855938b8
    • Chun-wei Fan's avatar
      codegen/extradefs/meson.build: Apply toolset version as well · 4eeaded9
      Chun-wei Fan authored
      We are already building the 'glibmm_generate_extra_defs-2.4' library with the
      toolset version applied by default on Visual Studio 2015+, so we should do the
      same here.
      4eeaded9
    • Chun-wei Fan's avatar
      Meson/Visual Studio builds: Include toolset version by default · 9d273d7a
      Chun-wei Fan authored
      This makes the built DLL and .lib's contain the toolset version if the build is
      carried out using Visual Studio 2015 or later, unless the
      'msvc14x-parallel-installable' option is set to be false during configuration.
      
      The reasoning behind this change is that there can be subtle problems when, for
      instance, one tries to link to a Visual Studio 2015-built atkmm when building
      items dependening on atkmm with Visual Studio 2017 or 2019.  This is
      unfortunate as Microsoft did try hard to make interoperating between binaries
      built with Visual Studio 2015, 2017 and 2019 as easy as possible in terms of ABI
      and API, but unfortunately this can hit the corner cases where this
      compatibility does not work.
      
      As the name suggests, this attempts to make Visual Studio 2015, 2017 and 2019
      builds share a single set of underlying C DLLs easier, while avoiding breakages
      caused by such subtle differences.
      9d273d7a
    • Chun-wei Fan's avatar
      Meson: Use pkg-config to find glibmm for all builds · 16a92ca3
      Chun-wei Fan authored
      Stop manually looking for glibmm for better consistency, as:
      
      -Items that depended on glibmm which added Meson build support after glibmm,
       such as gtkmm and libxml++ also required glibmm to be found via pkg-config
       files, and they still had NMake Makefile support for Visual Studio builds.
      -There could be corner cases on the glibmm libraries that atkmm links to in
       terms of ABI compatibility between Visual Studio 2015, 2017 and 2019.
      16a92ca3
  3. 16 Jun, 2020 1 commit
  4. 12 Jun, 2020 1 commit
    • Chun-wei Fan's avatar
      NMake Makefiles: Distinguish between MSVC 2015, 2017 and 2019 · 6994ec0d
      Chun-wei Fan authored
      It was found that we cannot completely rely on the fact that Visual
      Studio 2015~2019 tried very hard to be binary compatible, as there
      could be corner cases when linking against atkmm built with Visual
      Studio 2015 with builds done by Visual Studio 2017 and 2019 where
      the code will fail to link and the DLLs are therefore not
      ABI-compatible.  Note that the libsigc++ DLLs, however, are ABI
      compatible between these 3 Visual Studio versions.
      
      As a result, for the DLL and LIB names, use 'vc140' for Visual Studio
      2015 builds, 'vc141' for Visual Studio 2017 builds and 'vc142' for
      Visual Studio 2019 builds, according to the toolset versions as defined
      by Microsoft.
      
      For people that may have previously built atkmm (and glibmm) with Visual
      Studio 2017 or 2019, which had 'vc140' in the built .lib and DLL, an NMake
      option 'USE_COMPAT_LIBS' is added to make building such binaries with
      'vc140' easier, if needed.
      6994ec0d
  5. 17 Apr, 2020 3 commits
  6. 15 Apr, 2020 1 commit
  7. 13 Apr, 2020 2 commits
  8. 05 Apr, 2020 2 commits
    • Chun-wei Fan's avatar
      NMake Makefiles: Fix m4 file installation · 4db791dd
      Chun-wei Fan authored
      It should be in $(sharedir)/atkmm-x.y/proc/m4, not
      $(sharedir)/atkmm-x.y/proc.
      4db791dd
    • Chun-wei Fan's avatar
      NMake Makefiles: Export using compiler directives if possible · 96a19b0a
      Chun-wei Fan authored
      Check the gmmproc-generated sources to see whether they are generated
      with a new-enough gmmproc by checking on one of the generated headers,
      so that we can tell whether the generated headers have class, function
      and method definitions marked with ATKMM_API as needed.
      
      If the headers were generated with a recent enough gmmproc, we define
      ATKMM_BUILD and ATKMM_DLL to set ATKMM_API as __declspec(dllexport) to
      export the symbols directly during compilation and linking without
      building and using gendef.exe, otherwise we fall back to running
      gendef.exe on the built object files as we did before.
      96a19b0a
  9. 01 Apr, 2020 4 commits
    • Chun-wei Fan's avatar
      atk/atkmm/*.h: Mark methods with ATKMM_API · 7ab03a85
      Chun-wei Fan authored
      This way, we can export symbols in atkmm using compiler directives
      rather than using gendef.exe.
      7ab03a85
    • Chun-wei Fan's avatar
      atk/src/*.hg: Mark classes with ATKMM_API · 36825d00
      Chun-wei Fan authored
      This way, we can export the symbols in atkmm with compiler directives
      instead of using gendef.
      36825d00
    • Chun-wei Fan's avatar
      atk/atkmmconfig.h.in: Re-organize ATKMM_API definition · 7d15b453
      Chun-wei Fan authored
      We also activate ATKMM_DLL when we are building with Visual Studio, and
      define ATKMM_API as __declspec(dllexport) when ATKMM_DLL and ATKMM_BUILD
      are defined.
      
      Since we may be building with sources that are generated by gmmproc that
      did not support marking generated items with ATKMM_API, we also leave
      around a ATKMM_USE_GENDEF macro that would be defined if we find out
      that an older gmmproc was used to generate the sources from the .ccg/.hg
      files.
      7d15b453
    • Chun-wei Fan's avatar
      NMake Makefiles: Fix headers "installation" · 754b9eca
      Chun-wei Fan authored
      We may have generated the sources in $(Outdir)\atkmm, so make sure we
      look for the generated public headers there as well.
      754b9eca
  10. 31 Mar, 2020 5 commits
  11. 27 Feb, 2020 1 commit
  12. 07 Feb, 2020 3 commits
  13. 30 Dec, 2018 1 commit
    • Kjell Ahlstedt's avatar
      codegen/generate_defs_and_docs.sh: Update for non-source-dir builds · 063add1e
      Kjell Ahlstedt authored
      Most modules (e.g. atk) can be built in a directory separated from the
      source directory. Update the script that generates .defs and doc.xml files
      to handle that.
      The environment variables GMMPROC_GEN_SOURCE_DIR and GMMPROC_GEN_BUILD_DIR
      are read. See comments in init_generate.sh.
      063add1e
  14. 04 Nov, 2018 2 commits
  15. 31 Oct, 2018 1 commit
  16. 29 Oct, 2018 1 commit
    • Chun-wei Fan's avatar
      Update .gitignore · d0e8addc
      Chun-wei Fan authored
      The Visual Studio build files now reside in MSVC_NMake, not MSVC_201x.
      d0e8addc
  17. 26 Oct, 2018 4 commits
    • Chun-wei Fan's avatar
      build: Remove the Visual Studio 2013 projects · afaadd20
      Chun-wei Fan authored
      Since they have been replaced by the NMake Makefiles, it is time that
      they should be dropped.
      afaadd20
    • Chun-wei Fan's avatar
      build: Add a set of NMake Makefiles · f1a4846f
      Chun-wei Fan authored
      This is the set of NMake Makefiles that is used to build atkmm using
      Visual Studio 2013 and later, which will replace the current Visual
      Studio 2013 project files, so that the Visual Studio build files are
      easier to maintain.
      
      Note that for the C++-11 version of atkmm, the DLL and library that are
      generated from both the visual Studio 2015 and 2017 builds are
      atkmm-vc140-1_6.[dll|lib] or atkmm-vc140-d-1_6.[dll|lib] as both Visual
      Studio 2015 and 2017 link to the v140 Windows C/C++ runtime DLLs.
      f1a4846f
    • Chun-wei Fan's avatar
      atk/atkmm/filelist.am: Split out automake'ism · 69da40c2
      Chun-wei Fan authored
      Move the automake-specific part out so that this file can also be
      re-used by the NMake Makefiles.
      69da40c2
    • Chun-wei Fan's avatar
      builds: Rename MSVC_Net2013 to MSVC_NMake · 83763988
      Chun-wei Fan authored
      This is to prepare the transition of the Visual Studio build files to
      NMake Makefiles.
      83763988
  18. 25 Oct, 2018 1 commit
  19. 11 Sep, 2018 1 commit