"make dist" and cunit

[Greg Banks]

On Tue, Apr 24, 2012, at 10:46 AM, Jeroen van Meeuwen wrote:
> On Monday, April 23, 2012 03:05:24 PM Greg Banks wrote:
> > On Fri, Apr 20, 2012, at 12:15 PM, Дилян Палаузов wrote:
> > > Hello,
> > > 
> > > Can SMakefile be deleted?
> > 
> > I hope so.  Most of what's in there is useless and the rest is wrong.
> > 
> > It would be nice to have an autogen.sh which does all the necessary
> > autotools futzery, from aclocal to configure.
> > 
> 
> See attached (minor edits for the use of ~/tmp/ => ${TMPDIR:-/tmp} 
> notwithstanding).
> 
> > > Do we need "make snapshot" in addition to "make dist"?
> > 
> > The current dist: target seems to be broken; it fails on the master
> > branch because it's expecting a git tag which doesn't exist yet.  I
> > would expect it to always build a tarball but in this case indicate (in
> > both the xversion.h and the version number of the tarball) that the
> > tarball does not represent a tagged release.
> > 
> 
> The purpose of requiring a tag with the dist target was to prevent
> multiple 
> versions of cyrus-imapd-$x.$y.$z.tag.gz files from getting out there.

Agreed, a tarball that has a name like a release should be a release,
and not something else.

> It
> was 
> intended so that /make dist/ would fail, and someone would realize a
> /make 
> snapshot/ was what they wanted.
> 
> That said, if they are under the same target and end up having done the 
> correct thing in each situation, we're fine.

I'd prefer one target that does what you meant.

> + autogen-cyrus-imapd.sh
>   3k (application/x-shellscript)

Yes, like that, except it's purpose is not to record your particular
build - I have a script like that too :) - but to provide a quick way
for a person compiling Cyrus for the first time to get through the maze
of twisty little autotools.  Something more like:

#!/bin/sh
autoreconf -i -f -v -Icmulocal
./configure "$@"

So then a user can build from source by

- downloading the tarball
- autogen.sh
- make
- make check
- make install

This script looks like it was extracted from something a packaging
system ran, which is doing too much, like setting up C++ and Fortran
flags and forcing --with-perl and --bindir.  But it does raise some
interesting points:

* If there are actual C flags that need setting (and I can see good
arguments for using -D_FORTIFY_SOURCE=2 and -fstack-protector, on
systems where gcc is the compiler and those aren't already the system
compiler's default), then the configure script is the right place to do
that so everyone gets the benefit of them.

* Ditto warning flags - I would love to see at least -Wall -Wextra by
default if we're using gcc.

-- 
Greg.