make --enable-depend the default

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

* 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 && time make -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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Aug 6, 2013 at 6:59 AM, Robert Haas <robertmhaas@gmail.com> 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.

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.

Yes, this is for sure, even using environment variables dedicated to that
in multiple machines makes sense.
--
Michael

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers