Re: Configure dependencies can be the same as make dependencies

[Loic Dachary <loic@dachary.org>]

[-- Attachment #1: Type: text/plain, Size: 4237 bytes --]



On 05/05/2015 16:31, Gregory Farnum wrote:
> On Tue, May 5, 2015 at 1:34 AM, Loic Dachary <loic@dachary.org> 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...

The bit of context I forgot to mention is that ./configure is often used for the sole purpose of running make dist (with the risk of bundling stuff that does not actually build or run but that's not too much of a concern if the build is done immediately afterward, using the tarbal created by make dist).

> 
> 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
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]