On Tue, May 5, 2015 at 1:34 AM, Loic Dachary <loic@xxxxxxxxxxx> wrote: > 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 Maybe I'm missing something, but... configure's purpose in life is to set up the build system so that Ceph will successfully build on the current system. If configure assumes that you have stuff installed that you don't need to have installed to build, then it is not doing its job. Similarly, if "make check" won't run on a system that otherwise builds Ceph, that's a problem with "make check", not a problem with configure or the rest of Ceph. If we require *extra* dependencies to support make check that's very bad — it's becoming more popular for vendors to build Ceph on more exotic architectures and systems, and the chances are good that they'll do the minimal porting job, and simply skip running "make check" if it requires extra bits. Now, there are times when we decide something is important so we have configure default to one configuration and require a flag to change it. But in general that's not what we want to do, and IIRC there was an issue where configure was actually failing despite it being perfectly fine to build without some library or other. Etc etc. -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
