Commit 978c7b2e authored by Ondřej Surý's avatar Ondřej Surý Committed by Ondřej Surý
Browse files

Complete rewrite the BIND 9 build system

The rewrite of BIND 9 build system is a large work and cannot be reasonable
split into separate merge requests.  Addition of the automake has a positive
effect on the readability and maintainability of the build system as it is more
declarative, it allows conditional and we are able to drop all of the custom
make code that BIND 9 developed over the years to overcome the deficiencies of
autoconf + custom files.

This squashed commit contains following changes:

- conversion (or rather fresh rewrite) of all files to
  by using automake

- the libtool is now properly integrated with automake (the way we used it
  was rather hackish as the only official way how to use libtool is via

- the dynamic module loading was rewritten from a custom patchwork to libtool's
  libltdl (which includes the patchwork to support module loading on different
  systems internally)

- conversion of the unit test executor from kyua to automake ...
parent 4df5a583
Pipeline #39673 passed with stages
in 24 minutes and 15 seconds
......@@ -4,11 +4,13 @@
*.plist/ # ccc-analyzer store its results in .plist directories
*.ipch # vscode/intellisense precompiled header
......@@ -63,3 +65,4 @@ timestamp
......@@ -32,6 +32,7 @@ variables:
- autoconf
- precheck
- build
- unit
......@@ -168,7 +169,7 @@ stages:
.autoconf: &autoconf_job
<<: *release_branch_triggering_rules
<<: *base_image
stage: precheck
stage: autoconf
- autoreconf -fi
......@@ -186,6 +187,7 @@ stages:
--with-json-c \
--prefix=$HOME/.local \
--without-make-clean \
--with-python=python3 \
|| cat config.log
......@@ -253,8 +255,8 @@ stages:
- *setup_interfaces
- *setup_softhsm
- ( cd bin/tests/system && make -j${TEST_PARALLEL_JOBS:-1} -k test V=1 )
- test -s bin/tests/system/systests.output
- ( cd bin/tests/system && make -j${TEST_PARALLEL_JOBS:-1} -k check V=1 ) || cat bin/tests/system/test-suite.log
- test -s bin/tests/system/test-suite.log
.system_test: &system_test_job
<<: *system_test_common
......@@ -313,9 +315,7 @@ stages:
- *setup_softhsm
- make unit
- *kyua_report_html
- cd lib && make -j${TEST_PARALLEL_JOBS:-1} -k check V=1
.unit_test: &unit_test_job
<<: *unit_test_common
......@@ -328,16 +328,12 @@ stages:
<<: *unit_test_common
allow_failure: true
- *kyua_report_html
- find lib -name 'tsan.*' -exec python3 util/ {} \;
expire_in: "1 day"
- lib/*/tests/tsan.*
- tsan/
- kyua.log
- kyua.results
- kyua_html/
when: on_failure
.cppcheck_args: &run_cppcheck |
......@@ -377,7 +373,6 @@ autoreconf:
<<: *precheck_job
- sh util/
- sh util/ > checklibs.out
- sh util/tabify-changes < CHANGES > CHANGES.tmp
- diff -urNap CHANGES CHANGES.tmp
......@@ -451,16 +446,14 @@ tarball-create:
stage: precheck
<<: *base_image
- source version
- git archive --prefix="${BIND_DIRECTORY}/" --output="${BIND_DIRECTORY}.tar" HEAD
- mkdir "${BIND_DIRECTORY}"
- echo "SRCID=$(git rev-list --max-count=1 HEAD | cut -b1-7)" > "${BIND_DIRECTORY}/srcid"
- tar --append --file="${BIND_DIRECTORY}.tar" "${BIND_DIRECTORY}/srcid"
- *configure
- make -j${BUILD_PARALLEL_JOBS:-1} dist V=1
- bind-*.tar.${TARBALL_EXTENSION}
- bind-*.tar.*
- job: autoreconf
artifacts: true
- tags
......@@ -477,6 +470,7 @@ docs:
- job: autoreconf
artifacts: true
allow_failure: true
- doc/arm/
......@@ -524,7 +518,7 @@ gcc:centos6:amd64:
CC: gcc
EXTRA_CONFIGURE: "--with-libidn2 --disable-warn-error"
EXTRA_CONFIGURE: "--with-libidn2 --disable-warn-error --without-python"
<<: *centos_centos6_amd64_image
<<: *build_job
......@@ -805,7 +799,7 @@ gcc:tumbleweed:amd64:
CC: gcc
EXTRA_CONFIGURE: "--with-libidn2"
EXTRA_CONFIGURE: "--with-libidn2 --with-python"
<<: *tumbleweed_latest_amd64_image
<<: *build_job
......@@ -1152,77 +1146,17 @@ system:clang:openbsd6.6:amd64:
- schedules
- web
# Jobs for Visual Studio 2017 builds on Windows (amd64)
<<: *windows_build_job
<<: *default_triggering_rules
VSCONF: Release
<<: *windows_system_test_job
VSCONF: Release
- job: msvc:windows:amd64
artifacts: true
<<: *windows_build_job
- schedules
- tags
- web
<<: *windows_system_test_job
- job: msvc-debug:windows:amd64
artifacts: true
# Job producing a release tarball
<<: *base_image
stage: release
# Determine BIND version
- source version
# Remove redundant files and system test utilities from Windows build artifacts
- find Build/Release/ -name "*.pdb" -print -delete
- find Build/Debug/ \( -name "*.bsc" -o -name "*.idb" \) -print -delete
- find Build/ -regextype posix-extended -regex "Build/.*/($(find bin/tests/ -type f | sed -nE "s|^bin/tests(/system)?/win32/(.*)\.vcxproj$|\2|p" | paste -d"|" -s))\..*" -print -delete
# Create Windows zips
- openssl dgst -sha256 "${BIND_DIRECTORY}.tar.${TARBALL_EXTENSION}" | tee Build/Release/SHA256 Build/Debug/SHA256
- ( cd Build/Release; zip "../../BIND${BIND_DIRECTORY#bind-}" * )
- ( cd Build/Debug; zip "../../BIND${BIND_DIRECTORY#bind-}" * )
# Prepare release tarball contents (tarballs + zips + documentation)
- mkdir -p release/doc/arm
- pushd release
- mv "../${BIND_DIRECTORY}.tar.${TARBALL_EXTENSION}" ../BIND*.zip .
- tar --extract --file="${BIND_DIRECTORY}.tar.${TARBALL_EXTENSION}"
- mv "${BIND_DIRECTORY}"/doc/arm/{Bv9ARM{*.html,.pdf},man.*,notes.{html,pdf,txt}} doc/arm/
- rm -rf "${BIND_DIRECTORY}"
- cp doc/arm/notes.html "RELEASE-NOTES-${BIND_DIRECTORY}.html"
- cp doc/arm/notes.pdf "RELEASE-NOTES-${BIND_DIRECTORY}.pdf"
- cp doc/arm/notes.txt "RELEASE-NOTES-${BIND_DIRECTORY}.txt"
- popd
# Create release tarball
- tar --create --file="${CI_COMMIT_TAG}.tar.gz" --gzip release/
- job: tarball-create
artifacts: true
- job: msvc:windows:amd64
artifacts: true
- job: msvc-debug:windows:amd64
artifacts: true
- tags
Mark Andrews
Andreas Gustafsson
Evan Hunt
Brian Wellington
Bob Halley
David Lawrence
Michael Graff
Michael Sawyer
Ondřej Surý
James Brister
Tatuya JINMEI 神明達哉
Francis Dupont
Michał Kępień
Danny Mayer
Mukund Sivaraman
Jeremy C. Reed
William King
Stephen Morris
Witold Kręcicki
Curtis Blackburn
Scott Mann
Rob Austein
Jim Reid
Eric Luce
Olafur Gudmundsson
Stephen Jacob
Damien Neil
Tony Finch
Jakob Schlyter
Petr Menšík
Vernon Schryver
Matt Nelson
Shane Kerr
Paul Ebersman
Ray Bellis
Shawn Routhier
Ben Cottrell
Tomas Hozza
Bill Parker
Kevin Chen
Jonathan Casey
Mary Stahl
Mathieu Arnold
David Hankins
Paul Hoffman
Paul Vixie
Brian Conry
Anay Panvalkar
Robert Edmonds
João Damas
BIND 9 Code of Conduct
Like the technical community as a whole, the BIND 9 team and community is
made up of a mixture of professionals and volunteers from all over the
world, working on every aspect of the mission - including mentorship,
teaching, and connecting people.
Diversity is one of our huge strengths, but it can also lead to
communication issues and unhappiness. To that end, we have a few ground
rules that we ask people to adhere to. This code applies equally to the
core development team, open source contributors and those seeking help and
This isn't an exhaustive list of things that you can't do. Rather, take it
in the spirit in which it's intended - a guide to make it easier to enrich
all of us and the technical communities in which we participate.
This code of conduct applies to all spaces managed by the BIND 9 project
or Internet Systems Consortium. This includes chat, the mailing lists, the
issue tracker, and any other fora created by the project team which the
community uses for communication. In addition, violations of this code
outside these spaces may affect a person's ability to participate within
If you believe someone is violating the code of conduct, we ask that you
report it by emailing For more details please see our
Reporting Guidelines.
* Be friendly and patient.
* Be welcoming. We strive to be a community that welcomes and supports
people of all backgrounds and identities. This includes, but is not
limited to members of any race, ethnicity, culture, national origin,
colour, immigration status, social and economic class, educational
level, sex, sexual orientation, gender identity and expression, age,
size, family status, political belief, religion, and mental and
physical ability.
* Be considerate. Your work will be used by other people, and you in
turn will depend on the work of others. Any decision you take will
affect users and colleagues, and you should take those consequences
into account when making decisions. Remember that we're a world-wide
community, so you might not be communicating in someone else's primary
* Be respectful. Not all of us will agree all the time, but disagreement
is no excuse for poor behavior and poor manners. We might all
experience some frustration now and then, but we cannot allow that
frustration to turn into a personal attack. It's important to remember
that a community where people feel uncomfortable or threatened is not
a productive one. Members of the BIND 9 community should be respectful
when dealing with other members as well as with people outside the
BIND 9 community.
* Be careful in the words that you choose. We are a community of
professionals, and we conduct ourselves professionally. Be kind to
others. Do not insult or put down other participants. Harassment and
other exclusionary behavior aren't acceptable. This includes, but is
not limited to:
+ Violent threats or language directed against another person.
+ Discriminatory jokes and language.
+ Posting sexually explicit or violent material.
+ Posting (or threatening to post) other people's personally
identifying information ("doxing").
+ Personal insults, especially those using racist or sexist terms.
+ Unwelcome sexual attention.
+ Advocating for, or encouraging, any of the above behavior.
+ Repeated harassment of others. In general, if someone asks you to
stop, then stop.
* When we disagree, try to understand why. Disagreements, both social
and technical, happen all the time and BIND 9 is no exception. It is
important that we resolve disagreements and differing views
constructively. Remember that we're different. The strength of BIND 9
comes from its varied community, people from a wide range of
backgrounds. Different people have different perspectives on issues.
Being unable to understand why someone holds a viewpoint doesn't mean
that they're wrong. Don't forget that it is human to err and blaming
each other doesn't get us anywhere. Instead, focus on helping to
resolve issues and learning from mistakes.
Original text courtesy of the Django Code of Conduct project.
BIND Source Access and Contributor Guidelines
Feb 22, 2018
1. Access to source code
2. Reporting bugs
3. Contributing code
Thank you for using BIND!
BIND is open source software that implements the Domain Name System (DNS)
protocols for the Internet. It is a reference implementation of those
protocols, but it is also production-grade software, suitable for use in
high-volume and high-reliability applications. It is by far the most
widely used DNS software, providing a robust and stable platform on top of
which organizations can build distributed computing systems with the
knowledge that those systems are fully compliant with published DNS
BIND is and will always remain free and openly available. It can be used
and modified in any way by anyone.
BIND is maintained by the Internet Systems Consortium, a public-benefit
501(c)(3) nonprofit, using a "managed open source" approach: anyone can
see the source, but only ISC employees have commit access. Until recently,
the source could only be seen once ISC had published a release: read
access to the source repository was restricted just as commit access was.
That's now changing, with the opening of a public git mirror to the BIND
source tree (see below).
At Internet Systems Consortium, we're committed to building communities
that are welcoming and inclusive; environments where people are encouraged
to share ideas, treat each other with respect, and collaborate towards the
best solutions. To reinforce our commitment, the Internet Systems
Consortium has adopted the Contributor Covenant version 1.4 as our Code of
Conduct for BIND 9 project, as well as for the conduct of our developers
throughout the industry.
Access to source code
Public BIND releases are always available from the ISC FTP site.
A public-access GIT repository is also available at
. This repository is a mirror, updated several times per day, of the
source repository maintained by ISC. It contains all the public release
branches; upcoming releases can be viewed in their current state at any
time. It does not contain development branches or unreviewed work in
progress. Commits which address security vulnerablilities are withheld
until after public disclosure.
You can browse the source online via
To clone the repository, use:
$ git clone
Release branch names are of the form v9_X, where X represents the second
number in the BIND 9 version number. So, to check out the BIND 9.12
branch, use:
$ git checkout v9_12
Whenever a branch is ready for publication, a tag will be placed of the
form v9_X_Y. The 9.12.0 release, for instance, is tagged as v9_12_0.
The branch in which the next major release is being developed is called
Reporting bugs
Reports of flaws in the BIND package, including software bugs, errors in
the documentation, missing files in the tarball, suggested changes or
requests for new features, etc, can be filed using
Due to a large ticket backlog, we are sometimes slow to respond,
especially if a bug is cosmetic or if a feature request is vague or low in
priority, but we will try at least to acknowledge legitimate bug reports
within a week.
ISC's ticketing system is publicly readable; however, you must have an
account to file a new issue. You can either register locally or use
credentials from an existing account at GitHub, GitLab, Google, Twitter,
or Facebook.
Reporting possible security issues
If you think you may be seeing a potential security vulnerability in BIND
(for example, a crash with REQUIRE, INSIST, or ASSERT failure), please
report it immediately by emailing to Plain-text
e-mail is not a secure choice for communications concerning undisclosed
security issues so please encrypt your communications to us if possible,
using the ISC Security Officer public key.
Do not discuss undisclosed security vulnerabilities on any public mailing
list. ISC has a long history of handling reported vulnerabilities promptly
and effectively and we respect and acknowledge responsible reporters.
ISC's Security Vulnerability Disclosure Policy is documented at https://
If you have a crash, you may want to consult ?What to do if your BIND or
DHCP server has crashed.?
Contributing code
BIND is licensed under the Mozilla Public License 2.0. Earier versions
(BIND 9.10 and earlier) were licensed under the ISC License
ISC does not require an explicit copyright assignment for patch
contributions. However, by submitting a patch to ISC, you implicitly
certify that you are the author of the code, that you intend to reliquish
exclusive copyright, and that you grant permission to publish your work
under the open source license used for the BIND version(s) to which your
patch will be applied.
BIND code
Patches for BIND may be submitted directly via merge requests in ISC's
Gitlab source repository for BIND.
Patches can also be submitted as diffs against a specific version of BIND
-- preferably the current top of the master branch. Diffs may be generated
using either git format-patch or git diff.
Those wanting to write code for BIND may be interested in the developer
information page, which includes information about BIND design and coding
practices, including discussion of internal APIs and overall system
architecture. (This is a work in progress, and still quite preliminary.)
Every patch submitted will be reviewed by ISC engineers following our code
review process before it is merged.
It may take considerable time to review patch submissions, especially if
they don't meet ISC style and quality guidelines. If a patch is a good
idea, we can and will do additional work to bring it up to par, but if
we're busy with other work, it may take us a long time to get to it.
To ensure your patch is acted on as promptly as possible, please:
* Try to adhere to the BIND 9 coding style.
* Run make check to ensure your change hasn't caused any functional
* Document your work, both in the patch itself and in the accompanying
* In patches that make non-trivial functional changes, include system
tests if possible; when introducing or substantially altering a
library API, include unit tests. See Testing for more information.
Changes to configure
If you need to make changes to configure, you should not edit it directly;
instead, edit, then run autoconf. Similarly, instead of
editing directly, edit and run autoheader.
When submitting a patch as a diff, it's fine to omit the configure diffs
to save space. Just send the diffs and we'll generate the new
configure during the review process.
All functional changes should be documented. There are three types of
documentation in the BIND source tree:
* Man pages are kept alongside the source code for the commands they
document, in files ending in .docbook; for example, the named man page
is bin/named/named.docbook.
* The BIND 9 Administrator Reference Manual is mostly in doc/arm/
Bv9ARM-book.xml, plus a few other XML files that are included in it.
* API documentation is in the header file describing the API, in
Doxygen-formatted comments.
It is not necessary to edit any documentation files other than these; all
PDF, HTML, and nroff-format man page files will be updated automatically
from the docbook and XML files after merging.
Patches to improve existing documentation are also very welcome!
BIND is a large and complex project. We rely heavily on continuous
automated testing and cannot merge new code without adequate test
coverage. Please see the 'Testing' section of doc/dev/ for more
Thank you for your interest in contributing to the ongoing development of
\ No newline at end of file
\ No newline at end of file
This diff is collapsed.
include $(top_srcdir)/
SUBDIRS = . libltdl lib bin # doc
BUILT_SOURCES = bind.keys.h
CLEANFILES = bind.keys.h
bind.keys.h: bind.keys Makefile
${PERL} ${top_srcdir}/util/ < ${top_srcdir}/bind.keys > $@
dist_sysconf_DATA = bind.keys
# Hey Emacs, this is -*- makefile-automake -*- file!
# vim: filetype=automake
-DTESTS=\"$(abs_srcdir)\" \
# Hey Emacs, this is -*- makefile-automake -*- file!
# vim: filetype=automake
ACLOCAL_AMFLAGS = -I $(top_srcdir)/m4
-include $(top_builddir)/config.h \
-I$(top_srcdir)/include \
-I$(top_srcdir)/lib/isc/unix/include \
-I$(top_srcdir)/lib/isc/pthreads/include \
-I$(top_srcdir)/lib/isc/include \
LIBISC_LIBS = $(top_builddir)/lib/isc/
-I$(top_srcdir)/lib/dns/include \