----- Original Message ----- > From: "Gregory Farnum" <greg@xxxxxxxxxxx> > To: "Loic Dachary" <loic@xxxxxxxxxxx> > Cc: "Kefu Chai" <kchai@xxxxxxxxxx>, "Ceph Development" <ceph-devel@xxxxxxxxxxxxxxx> > Sent: Tuesday, May 5, 2015 10:31:11 PM > Subject: Re: Configure dependencies can be the same as make dependencies > > 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 yeah. we should rely on ./install-deps.sh to prepare the environment for all slaves. that's a more consistent and manageable way in the long term. @alfredo, what do you think? as to the change in https://github.com/ceph/ceph/pull/4544, my original intention was to port my quick fix in next branch back to the master, and to minimize the dependency for "configure; make dist". but now, i think it's but a way to please the developer who does not want to install sphinx-build. so it's just a nice-to-have now. and if "--without-man-pages", the configure dependencies and make dependencies are the same. i just updated https://github.com/ceph/ceph/pull/4449, to reference this mail thread. > > 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. agreed. but build includes "make check", IMHO. unless cross compiling. i think that's one of reasons why debhelper has dh_auto_test. debhelper is a set of tools helping building debian packages. i am not suggesting that "it is correct since it's working that way", but there is probably some rationale behind this, i think. > 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 one task of configure is to figure out the settings for Makefile. so, yes, it's a problem of "make check", but configure is responsible to help it. > 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. IIUC, this requires more fine-grained control to disable the check for dependencies only used in "make check". I am not sure if this is expected. for the good of the vendor who wants to port ceph to an exotic platform, a workable "make check" is always expected. at least "make check" for the part of ceph the venders want to port/build. for example, if the vendor just want to run ceph-osd on a certain platform, it would be nice to pass "--with-osd --without-mon --without-mds ..." to configure, and make sure that "make check" passes. and in this case, "make check" should only exercise the function of OSD and its dependencies. > > 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. Greg > > 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
