Thread: make --enable-depend the default

Hi,

People, including me, every now and then forget to pass --enable-depend
to configure (when not using my own environment). Which then leads to
strange errors that cost time to track down...

Thus I'd like to enable dependency tracking by default. Given todays
computing powers there doesn't seem to be much reason not to do so.

Any arguments against?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

Andres Freund <andres@2ndquadrant.com> writes:
> People, including me, every now and then forget to pass --enable-depend
> to configure (when not using my own environment). Which then leads to
> strange errors that cost time to track down...

> Thus I'd like to enable dependency tracking by default. Given todays
> computing powers there doesn't seem to be much reason not to do so.

> Any arguments against?

Yes: it's a waste of resources for one-shot builds, which is what most
people not reading this list do (and by asking here, you're biasing
your poll).

Personally I always do "make clean", if not "make distclean", after a git
pull.  If you're using ccache it's incredibly cheap to just rebuild the
whole tree every time, and I trust the results a lot more than I do
--enable-depend.

[postgres@sss1 pgsql]$ time make -s clean

real    0m1.613s
user    0m0.994s
sys     0m0.254s
[postgres@sss1 pgsql]$ time make -s -j8  
In file included from gram.y:13635:
scan.c: In function 'yy_try_NUL_trans':
scan.c:10167: warning: unused variable 'yyg'
All of PostgreSQL successfully made. Ready to install.

real    0m2.483s
user    0m6.693s
sys     0m2.123s

(make installcheck-parallel takes 13.6 seconds on this machine...)
        regards, tom lane

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> whole tree every time, and I trust the results a lot more than I do
> --enable-depend.

This is a much more compelling point, imv.  We definitely still have
issues around dependencies not being completely tracked, even with
--enable-depend.  Makes one wonder if maybe we should flip this around
and *remove* it..
Thanks,
    Stephen

On 2013-08-01 08:34:51 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > People, including me, every now and then forget to pass --enable-depend
> > to configure (when not using my own environment). Which then leads to
> > strange errors that cost time to track down...
> 
> > Thus I'd like to enable dependency tracking by default. Given todays
> > computing powers there doesn't seem to be much reason not to do so.
> 
> > Any arguments against?
> 
> Yes: it's a waste of resources for one-shot builds, which is what most
> people not reading this list do (and by asking here, you're biasing
> your poll).

I think the difference is resource usage is minimal enough for those
cases to not really matter. We only seem to support gcc's in-line
generation, so there's no separate gcc invocation for dependency
generation.

rm -rf /tmp/pgbuild/* && mkdir -p /tmp/pgbuild/ && cd /tmp/pgbuild && \  ~/src/postgresql/configure --enable-depend &&
timemake -j3 -s
 

All of PostgreSQL successfully made. Ready to install.
real   2m33.248s
user   3m58.657s
sys    0m26.282s

Without --enable-depend:
All of PostgreSQL successfully made. Ready to install.

real   2m32.853s
user   3m57.639s
sys    0m25.741s

ccached, fully cached:

make clean && time make -j3 -s:
real    0m7.394s
user    0m8.446s
sys     0m3.800s

without dependencies:
real    0m6.484s
user    0m7.824s
sys     0m3.278s

So if anything, that's the painpoint.

> Personally I always do "make clean", if not "make distclean", after a git
> pull.  If you're using ccache it's incredibly cheap to just rebuild the
> whole tree every time, and I trust the results a lot more than I do
> --enable-depend.

Funnily I repeatedly had problems that could only be solved by clearing
ccache's cache... I am not really worried about rebuilds after a pull,
but more about iterative rebuilds while writing code. Including header
changes.

> [postgres@sss1 pgsql]$ time make -s clean
> 
> real    0m1.613s
> user    0m0.994s
> sys     0m0.254s
> [postgres@sss1 pgsql]$ time make -s -j8  
> In file included from gram.y:13635:
> scan.c: In function 'yy_try_NUL_trans':
> scan.c:10167: warning: unused variable 'yyg'
> All of PostgreSQL successfully made. Ready to install.
> 
> real    0m2.483s
> user    0m6.693s
> sys     0m2.123s
> 
> (make installcheck-parallel takes 13.6 seconds on this machine...)

Hrmpf. It takes longer than that for me. I need a new laptop...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

On Thu, 2013-08-01 at 11:10 +0200, Andres Freund wrote:
> People, including me, every now and then forget to pass --enable-depend
> to configure (when not using my own environment). Which then leads to
> strange errors that cost time to track down...

One argument against that is that we only support dependency tracking
with GCC, so we would have to either fail configure or use a different
default depending on the compiler.

It's also unreasonable to assume, I think, that just turning on
--enable-depend by default will eliminate forgot-a-configure-option
mistakes.  In most cases, you want to turn on most or all --enable-* and
--with-* options to get good build and test coverage.

On Mon, Aug 5, 2013 at 4:18 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> On Thu, 2013-08-01 at 11:10 +0200, Andres Freund wrote:
>> People, including me, every now and then forget to pass --enable-depend
>> to configure (when not using my own environment). Which then leads to
>> strange errors that cost time to track down...
>
> One argument against that is that we only support dependency tracking
> with GCC, so we would have to either fail configure or use a different
> default depending on the compiler.
>
> It's also unreasonable to assume, I think, that just turning on
> --enable-depend by default will eliminate forgot-a-configure-option
> mistakes.  In most cases, you want to turn on most or all --enable-* and
> --with-* options to get good build and test coverage.

Yeah, I have alias dev-configure='./configure
--appropriate-stuff-for-this-machine' on every system where I work on
PG.  I imagine others do something similar.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2013-08-05 17:59:39 -0400, Robert Haas wrote:
> On Mon, Aug 5, 2013 at 4:18 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> > On Thu, 2013-08-01 at 11:10 +0200, Andres Freund wrote:
> >> People, including me, every now and then forget to pass --enable-depend
> >> to configure (when not using my own environment). Which then leads to
> >> strange errors that cost time to track down...
> >
> > One argument against that is that we only support dependency tracking
> > with GCC, so we would have to either fail configure or use a different
> > default depending on the compiler.
> >
> > It's also unreasonable to assume, I think, that just turning on
> > --enable-depend by default will eliminate forgot-a-configure-option
> > mistakes.  In most cases, you want to turn on most or all --enable-* and
> > --with-* options to get good build and test coverage.

Part of it is that just about any other project has the default to
enable dependency tracking, so people aren't aware of having to do that.

> Yeah, I have alias dev-configure='./configure
> --appropriate-stuff-for-this-machine' on every system where I work on
> PG.  I imagine others do something similar.

I have that on machines I work on regularly as well, but on others where
I don't control everything...

Anyway, ISTM people don't agreee, so let's consider this proposal retracted.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services

Andres Freund <andres@2ndquadrant.com> writes:
> On 2013-08-05 17:59:39 -0400, Robert Haas wrote:
>> Yeah, I have alias dev-configure='./configure
>> --appropriate-stuff-for-this-machine' on every system where I work on
>> PG.  I imagine others do something similar.

> I have that on machines I work on regularly as well, but on others where
> I don't control everything...

Personally, I have a small tarball of shell scripts that I install in
~/bin on any machine where I'm asked to poke at PG problems.  One of them
is a frontend for configure that sets it up the way I like.

If the vote went against me on this point, I'd add --disable-depend to
that script and the problem would be solved so far as my personal wants
were concerned.  It remains though that such a default would be wasting
build cycles forevermore for a majority of non-developers.

Peter's point about the GCC-dependence of such a default seems pretty
killer from here, too.
        regards, tom lane