Hi Kefu, In the context of https://github.com/ceph/ceph/pull/4449 and https://github.com/ceph/ceph/pull/4544 I see you're going out of your way to implement mechanisms that make it possible to require less dependencies when running ./configure than what is required by ./make check I think the right solution is to require the same set of dependencies, regardless. It can easily be done by running ./install-deps.sh[1]. This script is already used in jenkins.ceph.com and saved us from the recurring pain of manually updating the jenkins slaves every time a dependency was added to either ceph.spec.in or debian/control. Although it is possible to run ./configure with a subset of the dependencies that are required to run make check, it trades automatic installation of packages for significant manual maintenance. It saves a little disk and bandwidth every time a dependency is modified in the ceph.spec.in or debian/control files, which happens a few times a months at most. The work items to manually maintain this difference: * the set of dependencies that ./configure requires needs to be manually maintained, it is not listed anywhere at the moment. It changes less often than ceph.spec.in or debian/control but it does change from time to time * the configure script has to be engineered to only require dependencies (assuming these dependencies are listed somewhere). In other word, every time you change the configure script you have to be extra careful to not introduce a new dependency, even when it would help implement what you're after in a simpler way. * the configure script dependencies in the context of CI actually change every time you consider using --enable-something because it modifies the set of files your tarbal is made of. If the corresponding something is not installed, the configure will likely not do what you want and you'll have to add something manually on the CI machine (or use install-deps.sh but that would defeat the purpose of separating configure dependencies from make dependencies) * to avoid adding dependencies to configure, it is tempting to forbid file generation when preparing the tarbal (I'm thinking .8 generation specifically), although it is legitimate for the tarbal generation to involve some processing and transformation of the sources that require tools to run * it is very unlikely a new developer will remember configure dependencies and make dependencies are different and mistakes will be done all the time, creating needless frustration Cheers [1] https://github.com/ceph/ceph/blob/master/install-deps.sh -- Loïc Dachary, Artisan Logiciel Libre
Attachment:
signature.asc
Description: OpenPGP digital signature
