Required make version

Peter Eisentraut <peter_e@gmx.net> writes:

There is a build farm failure now because (apparently) an old make version:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dawn_bat&amp;dt=2008-02-26%2019:00:01

The new amended backend linking code needs GNU make 3.80, released 2002-10-03.

Are you sure you've diagnosed this correctly? I built last night with
make 3.79.1 without any obvious problem. OTOH I haven't yet tracked
the commits you made today.

regards, tom lane

Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

There is a build farm failure now because (apparently) an old make version:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=dawn_bat&amp;dt=2008-02-26%2019:00:01

The new amended backend linking code needs GNU make 3.80, released 2002-10-03.

Are you sure you've diagnosed this correctly? I built last night with
make 3.79.1 without any obvious problem. OTOH I haven't yet tracked
the commits you made today.

only objfiles.txt uses the somewhat arcane feature that is apparently
breaking dawn_bat - it is apparently not used anywhere else in our build
system.

Is that really the only way we can do it? Maybe Peter understands it but
I don't, and I'm not sure I want to invest lots of brain cells in
finding out.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

only objfiles.txt uses the somewhat arcane feature that is apparently
breaking dawn_bat - it is apparently not used anywhere else in our build
system.

Is that really the only way we can do it? Maybe Peter understands it but
I don't, and I'm not sure I want to invest lots of brain cells in
finding out.

Yeah, I'm not seeing why we should suddenly need a make feature we never
needed before ...

regards, tom lane

Tom Lane wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

only objfiles.txt uses the somewhat arcane feature that is apparently
breaking dawn_bat - it is apparently not used anywhere else in our build
system.

Is that really the only way we can do it? Maybe Peter understands it but
I don't, and I'm not sure I want to invest lots of brain cells in
finding out.

Yeah, I'm not seeing why we should suddenly need a make feature we never
needed before ...

This was in response to your request

BTW, why does this patch force objfiles.txt to be regenerated every time
any individual .o file is rebuilt? Surely it need only depend on the
specific Makefile (and maybe Makefile.global).

I find the current behavior kind of annoying because the echo command
occupies more than a full window in some subdirectories (eg utils/adt),
making it necessary to scroll back to see whether one's recompile of a
couple of modified files generated any warnings.

In the original implementation, objfiles.txt needs to be regenerated every
time an .o file is rebuilt

1) to tell make to build the .o files in the first place, and
2) to rebuild postgres by looking when an objfiles.txt file has changed.

Using the order-only prerequisites feature, which is what is failing with the
old make version, solves item 1).

The alternative is your suggestion

If the dependencies
need to stay as they are, maybe we could avoid the annoyance by having
make not print the echo command.

but I'm not a friend of hiding commands because you don't know what is going
on and it will come back to bite you.

So obviously, there are a few possible solutions. We just have to pick one we
like best.

We could actually query make whether it supports order-only prerequisites and
only use the developer-optimized rules in that case. That would mean,
however, that the optimized rules would only be used with GNU make 3.81 or
higher. I read earlier that you use 3.79.1, so then you still wouldn't get
the behavior you want.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut <peter_e@gmx.net> writes:

... This was in response to your request

So obviously, there are a few possible solutions. We just have to
pick one we like best.

Check.

We could actually query make whether it supports order-only prerequisites and
only use the developer-optimized rules in that case. That would mean,
however, that the optimized rules would only be used with GNU make 3.81 or
higher. I read earlier that you use 3.79.1, so then you still wouldn't get
the behavior you want.

Well, it's not that I'm unwilling to install something newer, but I
deliberately run a trailing-edge toolchain on this particular machine
as a sanity check on what we require to build. I don't think we should
increase our build tool requirements without a fairly good reason, and
my essentially-cosmetic request doesn't seem to me to be a good enough
reason.

Of the alternatives mentioned so far, suppressing the command echo
really seems the best to me ...

regards, tom lane

Peter Eisentraut wrote:

Using the order-only prerequisites feature, which is what is failing with the
old make version, solves item 1).

The alternative is your suggestion

If the dependencies
need to stay as they are, maybe we could avoid the annoyance by having
make not print the echo command.

but I'm not a friend of hiding commands because you don't know what is going
on and it will come back to bite you.

How about we use order-only prerequisite only if present, and use the
ugly or undesirable way as fallback? I see that you can find out if
your Make version supports it by checking .FEATURES.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

Alvaro Herrera wrote:

How about we use order-only prerequisite only if present, and use the
ugly or undesirable way as fallback? I see that you can find out if
your Make version supports it by checking .FEATURES.

I think this can be used with a conditional like

ifneq (,$(findstring order-only,$(.FEATURES)))
...
endif

I am not sure I understand the problem being complained about to propose
a more specific patch.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Alvaro Herrera wrote:

I think this can be used with a conditional like

ifneq (,$(findstring order-only,$(.FEATURES)))
...
endif

Yes, that was my thought.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/