1. 28 Jul, 2020 1 commit
  2. 28 May, 2020 3 commits
  3. 15 Apr, 2020 2 commits
    • Ondřej Surý's avatar
      Disable MSB8028 warning · b6c2012d
      Ondřej Surý authored
      All our MSVS Project files share the same intermediate directory.  We
      know that this doesn't cause any problems, so we can just disable the
      detection in the project files.
      
      Example of the warning:
      
        warning MSB8028: The intermediate directory (.\Release\) contains files shared from another project (dnssectool.vcxproj).  This can lead to incorrect clean and rebuild behavior.
      b6c2012d
    • Ondřej Surý's avatar
      Set WarningLevel to Level1 for Release, treat warnings as errors · 789d253e
      Ondřej Surý authored
      Our vcxproj files set the WarningLevel to Level3, which is too verbose
      for a code that needs to be portable.  That basically leads to ignoring
      all the errors that MSVC produces.  This commits downgrades the
      WarningLevel to Level1 and enables treating warnings as errors for
      Release builds.  For the Debug builds the WarningLevel got upgraded to
      Level4, and treating warnings as errors is explicitly disabled.
      
      We should eventually make the code clean of all MSVC warnings, but it's
      a long way to go for Level4, so it's more reasonable to start at Level1.
      
      For reference[1], these are the warning levels as described by MSVC
      documentation:
      
        * /W0 suppresses all warnings. It's equivalent to /w.
        * /W1 displays level 1 (severe) warnings. /W1 is the default setting
          in the command-line compiler.
        * /W2 displays level 1 and level 2 (significant) warnings.
        * /W3 displays level 1, level 2, and level 3 (production quality)
          warnings. /W3 is the default setting in the IDE.
        * /W4 displays level 1, level 2, and level 3 warnings, and all level 4
          (informational) warnings that aren't off by default. We recommend
          that you use this option to provide lint-like warnings. For a new
          project, it may be best to use /W4 in all compilations. This option
          helps ensure the fewest possible hard-to-find code defects.
        * /Wall displays all warnings displayed by /W4 and all other warnings
          that /W4 doesn't include — for example, warnings that are off by
          default.
        * /WX treats all compiler warnings as errors. For a new project, it
          may be best to use /WX in all compilations; resolving all warnings
          ensures the fewest possible hard-to-find code defects.
      
      1. https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2019
      789d253e
  4. 26 Sep, 2019 1 commit
    • Michał Kępień's avatar
      Make VS solution upgrading unnecessary · 0476e8f1
      Michał Kępień authored
      Until now, the build process for BIND on Windows involved upgrading the
      solution file to the version of Visual Studio used on the build host.
      Unfortunately, the executable used for that (devenv.exe) is not part of
      Visual Studio Build Tools and thus there is no clean way to make that
      executable part of a Windows Server container.
      
      Luckily, the solution upgrade process boils down to just adding XML tags
      to Visual Studio project files and modifying certain XML attributes - in
      files which we pregenerate anyway using win32utils/Configure.  Thus,
      extend win32utils/Configure with three new command line parameters that
      enable it to mimic what "devenv.exe bind9.sln /upgrade" does.  This
      makes the devenv.exe build step redundant and thus facilitates building
      BIND in Windows Server containers.
      0476e8f1
  5. 08 Mar, 2019 1 commit
  6. 10 Aug, 2018 1 commit
  7. 19 Jul, 2018 1 commit
  8. 22 Feb, 2018 1 commit
  9. 08 Sep, 2017 1 commit
    • Evan Hunt's avatar
      [master] add libns and remove liblwres · 8eb88aaf
      Evan Hunt authored
      4708.   [cleanup]       Legacy Windows builds (i.e. for XP and earlier)
                              are no longer supported. [RT #45186]
      
      4707.	[func]		The lightweight resolver daemon and library (lwresd
      			and liblwres) have been removed. [RT #45186]
      
      4706.	[func]		Code implementing name server query processing has
      			been moved from bin/named to a new library "libns".
      			Functions remaining in bin/named are now prefixed
      			with "named_" rather than "ns_".  This will make it
      			easier to write unit tests for name server code, or
      			link name server functionality into new tools.
      			[RT #45186]
      8eb88aaf
  10. 20 Apr, 2017 1 commit
  11. 30 Jan, 2016 1 commit
  12. 27 Jan, 2016 1 commit
  13. 04 Jan, 2016 1 commit
  14. 27 Aug, 2015 1 commit
  15. 21 Feb, 2015 1 commit
  16. 12 Feb, 2014 1 commit
  17. 14 Jan, 2014 1 commit
    • Evan Hunt's avatar
      [master] native PKCS#11 support · ba751492
      Evan Hunt authored
      3705.	[func]		"configure --enable-native-pkcs11" enables BIND
      			to use the PKCS#11 API for all cryptographic
      			functions, so that it can drive a hardware service
      			module directly without the need to use a modified
      			OpenSSL as intermediary (so long as the HSM's vendor
      			provides a complete-enough implementation of the
      			PKCS#11 interface). This has been tested successfully
      			with the Thales nShield HSM and with SoftHSMv2 from
      			the OpenDNSSEC project. [RT #29031]
      ba751492
  18. 04 Dec, 2013 1 commit