On 06-06-2008 08:49:45 +0200, Niels Nes wrote:
On Fri, Jun 06, 2008 at 08:28:10AM +0200, Stefan Manegold wrote:
To solve this "dilemma", I came up with the idea to make the default setting "more flexible" and "automatically detect" whether a developer is compiling from CVS or a user is compiling from source tarball(s). In the former case, the default is "--enable-strict", it the latter it is "--disable-strict".
Here's my patch: ======== --- buildtools/conf/MonetDB.m4 24 May 2008 17:13:41 -0000 1.75.2.1 +++ buildtools/conf/MonetDB.m4 6 Jun 2008 06:14:32 -0000 @@ -17,7 +17,15 @@ dnl Defaults that differ between development trunk and release branch: AC_DEFUN([AM_MONETDB_DEFAULTS], [ -dft_strict=no +if test -f "$srcdir"/vertoo.data; then + dnl Developers compiling from CVS: + dnl default is --enable-strict + dft_strict=yes +else + dnl Users compiling from source tarball(s): + dnl default is --disable-strict + dft_strict=no +fi
Would it be possible to do this check based on the existence of a .CVS directory?
In case there are no (strong) objections, I'd like to check this in later today.
Open question: shall we only do this on the release branch and keep "--enable-strict" as default in all cases in the development trunk, or shall we apply the same strategy o the development trunk, too?
Same strategy sounds good for the development trunk too. There the users of the tar.balls also may have other platforms.
It would make sense to me if the nightly tarballs, which include the superballs all compile with strict, optimize and assert being *disabled* by default, for a sane code distribution. Please note that for some compiler issues to catch, one has to use -O2 (--enable optimize?), however doing that makes the binary hard to debug, which results in a natural inconvenience here...