[bind10-dev] splitting up BIND 10 to install different features

[Stephen Morris]

On 16/02/12 13:07, Stephen Morris wrote:
> On 16/02/2012 12:24, Tomek Mrugalski wrote:
> 
> That might be simplest, although there may be potential problems,
> e.g. if I --enable-auth (for example) would that mean I
> automatically build core?  And if I do, what if I want to install
> auth in one place and resolver in another - do I end up with two
> copies of the libraries? (Why anyone would want to do that is
> another matter, but you can be certain that if it is possible,
> someone, somewhere, will do it.)

This issue has come up again as we start DHCP development in earnest
this year. So that we don't get stuck in "analysis paralysis", I
suggest that initially we have three configure flags (we can always
change them later):

--disable-dns - Do not build the DNS part of the system
--disable-dhcp - Do not build the DHCP part of the system
--disable-tools - Do not build associated tools (currently only perfdhcp)

If no flags are specified, build everything.

If go with this breakdown, I would suggest that we split the job
running on the build farm into two, one built with "--disable-dhcp
--disable-tools" and one built with "--disable-dns".  That way, if
there is a build failure in a DNS/DHCP-specific module, the other
team's testing does not get stalled.

Periodically though, we should build and test everything in one pass.

> I can't help feeling that treating the different packages as
> separate products (each with their own source tree) will end up
> being the easiest way handle this. Although some overarching way of
> making everything in one command - perhaps a special configure
> script with the --enable-X and --disable-X options described above
> - will be needed.

Thinking it through, I've changed my mind here - there is so much
overlap between DHCP and DNS (e.g. both require the message queue,
both require the configuration manager etc.) that a single source tree
is easiest.

Stephen