Solution A
-----------------
One possibility is to take advantage of jenkins functionality and utilise its build matrix. For example it could be set up so that only a smallish set of jobs are needed:

  Build_Botan
  Build_LDNS
  Build_an_other_dependancy
  Build_SoftHSM
  Build_OpenDNSSEC

  Test_libhsm
  Test_enforcer
  Test_an_other_test

  Run_OpenDNSSEC
  Run_SoftHSM

Jobs called Build_X - will build dependancies (such as Botan and LDNS) and major components of OpenDNSSEC (i.e. SoftHSM and OpenDNSSEC) They will build the code, run 'make checks' and install the software into a set of 'fakeroot' directories (see below for details).

  - The jenkins jobs are 2 dimensional for dependancies in OS and application version. See what this looks like in jenkins here:  https://jenkins.opendnssec.org/job/Build_Botan/

  - The jenkins jobs are multidimensional for the major components in OS, component version and a version for each dependancy (because they will need to be tested against all (many?) versions of the dependancies). A mock-up of what this might look like for SoftHSM can be found here: https://jenkins.opendnssec.org/job/Dummy_Build_SoftHSM/  showing a the dimensions of OS, SoftHSM version and Botan version. A slightly more complex example for the OpenDNSSEC component showing a dependancy on both SoftHSM and LDNS is shown here: https://jenkins.opendnssec.org/job/Dummy_Build_OpenDNSSEC/

Jenkins will build all possible combinations of the matrix, however it is possible to filter out unnecessary ones.

Jobs called Test_ X - will build and run 'make check' on more minor components of OpenDNSSEC. They exist for to make it easier to find failing checks, for example just building and testing libhsm. They do not install anything.

Jobs called Run_X - will use the installed major components of OpenDNSSEC (installed by the Build_X jobs) and run end-to-end system tests on them. These tests are again multidimensional in OS, component version and a version for each dependancy. So the jenkins results would look similar to the examples above for the Build_X jobs.

Install directories - the Build_X jobs for the major components will create a set of installation directories with a suggested naming scheme of  /fakeroot/component/component_version/dep1_dep2_dep3  for example /fakeroot/OpenDNSSECM/trunk/ldns1.6.12_SoftHSM1.3.0/. The Build_X jobs for the dependancies will use a naming scheme such as /fakeroot/Botan-1.8.13/.

PROs:
- Dependancies (e.g. botan) have the source in one location and are only built once
- Results are displayed in a matrix so patterns of failure are easy to spot
- Jenkins dashboard has a small number of jobs
- Able to turn off unnecessary parts of the build matrix

CONs:
- Have to drill down one page from the dashboard to see exactly which test(s) failed