Re: DTrace build dependency rules

On Tue, Aug 18, 2015 at 12:08 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Robert Haas wrote:
>> On Sat, Aug 15, 2015 at 6:45 PM, Mark Johnston <markj(at)freebsd(dot)org> wrote:
>
>> > The bug is in src/backend/Makefile. probes.o, the dtrace(1)-generated
>> > object file, depends on the objfiles.txt for each of the backend
>> > subdirs. These files depend in turn on the object files themselves; if
>> > objfiles.txt is out of date with respect to one of its object files, the
>> > mtime of objfiles.txt is updated with "touch" (see backend/common.mk).
>> > The problem is that dtrace -G, which runs at the end of the build,
>> > modifies a number of object files (it overwrites their probe sites with
>> > NOPs), thus making their corresponding objfiles.txt out of date. Then,
>> > when "make install" traverses the backend subdirs, it updates
>> > objfiles.txt, which causes probes.o to be rebuilt, resulting in an error
>> > from dtrace(1).
>>
>> Gosh, that's pretty ugly. I would have thought it would be a real
>> no-no to update the .o file once it got generated. If nothing else, a
>> modification to the .c file concurrent with a make invocation might
>> lead to the .o not getting rebuilt the next time make is run.
>
> I had the same thought, and wondered for a bit whether we should instead
> have the compilation rules produce some intermediate file (prior to
> dtrace fumbling), then emit the .o from dtrace -G. OTOH this might be
> more trouble than is worth for a feature that doesn't see a lot of use.

Given the lack of further interest from the PostgreSQL community,
that's my guess. I've pushed this patch to master; let's see if we
get any complaints. If it makes life better for FreeBSD without
making life worse for anyone else, I suppose we might as well do it
until something better comes along.

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