From: Loic Dachary <loic@dachary.org>
To: Kefu Chai <kchai@redhat.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Configure dependencies can be the same as make dependencies
Date: Tue, 05 May 2015 10:34:02 +0200 [thread overview]
Message-ID: <5548807A.6060103@dachary.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]
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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next reply other threads:[~2015-05-05 8:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-05 8:34 Loic Dachary [this message]
2015-05-05 14:31 ` Configure dependencies can be the same as make dependencies Gregory Farnum
2015-05-05 14:36 ` Loic Dachary
2015-05-05 18:59 ` Ken Dreyer
2015-05-05 19:07 ` Loic Dachary
2015-05-05 19:31 ` Sage Weil
2015-06-09 17:11 ` Owen Synge
2015-06-09 17:19 ` what this would look like if the system is with templates Owen Synge
2015-06-09 23:06 ` Ken Dreyer
2015-06-10 10:44 ` Owen Synge
2015-06-09 17:22 ` Configure dependencies can be the same as make dependencies Sage Weil
2015-06-09 18:23 ` Owen Synge
2015-06-09 18:44 ` Sage Weil
2015-06-09 19:23 ` Owen Synge
2015-05-05 17:15 ` Kefu Chai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5548807A.6060103@dachary.org \
--to=loic@dachary.org \
--cc=ceph-devel@vger.kernel.org \
--cc=kchai@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.