qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Farrellee <mfarrel...@redhat.com>
Subject Re: [c++] Simplifying our distribution packaging.
Date Fri, 16 May 2008 18:03:35 GMT
Ted Ross wrote:
> Alan Conway wrote:
>> Currently the C++ distribution tarball is not "pure source", as it 
>> contains generated source and documentation files that are 
>> pre-generated while building the distribution. This is bad (see below 
>> for details of why.) I'd like to move towards a pure-source 
>> distribution, proposal below.
>>
>> == Why the current situation is bad
>>
>>  - In a normal project "make dist" is quick - it basically just 
>> creates a tarball. In qpid "make dist" is slow - it does an entire 
>> build because needs qpidd in order to generate the man page from qpidd 
>> --help.
>>
>>  - "make distcheck" takes twice as long as it should because it does 
>> *two* builds, first to generate the man page, then to build the real 
>> distro.
>>
>>  - "make distcheck" and VPATH builds are frequently broken (I think 
>> both are broken right now) because of confusion over whether generate 
>> sourced code is in "srcdir" or "builddir". It should be in builddir 
>> when building from scratch, but inevitably ends up in srcdir in a 
>> distro tarball. Getting the build system to work properly in both 
>> scenarios is tricky.
>>
>> The results of all the above is that people avoid building distros 
>> like the plague because it's slow and likely to fail, and therefore we 
>> get very little testing of the distro-buildingn process.
>>
>> == Why did I get us into this mess in the first place?
>>
>> There was a desire to let people build the distro without having all 
>> of the dependencies required to build generated source & docs. At the 
>> time, the code generator was in Java, which is a totally unacceptable 
>> dependency for a C or C++ project, so this was probably the right 
>> thing to do. That is no longer the case - the current generator is in 
>> ruby - so I don't think the original reasoning holds.
>>
>> I'd like to go towards a pure source distribution, with ruby as a 
>> requirement to build. I'd like to make some other requirements 
>> optional, i.e. if present they add functionality but you can do a 
>> basic build without them:
>>  - python: run python test suite if present.
>>  - doxygen: generate API doc if present.
>>  - graphviz: add class diagrams to API doc if present
>>  - help2man: generate man page if present.
>>
>> I think this gives us a reasonable minimal requirement set (only 
>> adding ruby) and provides flexibility to do a basic build without all 
>> the doc tools. We can provide  generated documentation on the project 
>> web pages for people  who cant/dont want to build it themselves.
>>
>> Any objections?
> No.  I think this is a good idea.  However python can't be optional 
> since the code generation for management uses it.
> 
> -Ted

Sounds like a good idea. Where is the AMQP spec going to come from for 
code generation? Would you include it in the dist somehow, or make it 
another dependency?

I'm assuming you are talking about a qpid/cpp/ dist, which has a 
dependency on qpid/specs/ for a spec.

If you include the spec in the dist you're still not generating a 
completely pure tarball, since you'll need a rule to pull it from 
qpid/specs/, a rule that won't have proper dependencies to detect 
changes in qpid/specs/. However, having a spec be an added dependency 
seems overly burdensome for someone who wants to download qpid C++ and 
build it.

Given these two evils I'd probably go with the former.

Best,


matt

Mime
View raw message