Re: dependencies for generated header files

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: dependencies for generated header files
Date: 2009-08-11 21:28:06
Message-ID: 603c8f070908111428p373c9c30o27e15c8716b05f04@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 11, 2009 at 4:38 PM, Peter Eisentraut<peter_e(at)gmx(dot)net> wrote:
> On Sunday 28 June 2009 21:21:35 Robert Haas wrote:
>> I think that our dependencies for generated header files (gram.h,
>> fmgroids.h, probes.h) are not as good as they could be.  What we do
>> right now is make src/backend/Makefile rebuild these before recursing
>> through its subdirectories.  This works OK for a top-level make, but
>> if you run make further down in the tree (like under
>> src/backend/commands) it won't necessarily rebuild everything that it
>> should.
>>
>> The attached patch moves some of this logic from src/backend/Makefile
>> to src/Makefile.global.in.  That way, if you --enable-depend and then
>> do something like "touch src/include/catalog/pg_proc.h" and then "cd
>> src/backend/commands; make vacuum.o", it rebuilds fmgroids.h and then
>> recompiles vacuum.c.  Under HEAD, it just tells you that vacuum.o is
>> up to date.
>
> I'm not convinced by this use case.  Why do you want to rebuild vacuum.o
> anyway?  If you change something, then you probably want to rebuild postgres,
> and that works fine without this change.

Well, my original motivation for developing this patch was that I
often go into a subdirectory and start hacking on a .c file and then
type make to rebuild just that subdirectory (so it's easier to see
warnings and errors). But sometimes I would edit a relevant header
file and then the rebuild wouldn't happen. That bugged me. Your
mileage may vary.

> I'm concerned how this change moves random make rules into a global makefile.
> This is exacerbated by your next patch, which among other things moves the
> entire catalog list to build the various output files into Makefile.global,
> far away from its home.

*shrug* You don't have to accept the patch, but I'm unclear as to how
make from a subdirectory will ever work reliably without something
like this. The problem occurs when .c files have dependencies on
files that are generated by a Makefile in some other subdirectory. So
it's not random stuff: it's the stuff where that particular thing
happens.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pierre Frédéric Caillaud 2009-08-11 21:29:00 Re: "Hot standby"?
Previous Message Josh Berkus 2009-08-11 21:23:59 Re: Why is vacuum_freeze_min_age 100m?