Re: dependencies for generated header files

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: dependencies for generated header files
Date: 2009-08-12 01:40:57
Message-ID: 603c8f070908111840t584340f2sba0c540693c19453@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 11, 2009 at 9:19 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Aug 11, 2009 at 9:00 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Surely the answer to that is "you should be configuring with --enable-depend".
>
>> Uhm, the point is that this is broken even with ---enable-depend.
>
> Oh, okay, but that's only for *generated* header files.  I'm not excited
> about that.  We've pretty much managed to minimize compile-time
> dependencies on generated files.  Now of course your other patch wants
> to vastly expand the use of generated files, and I can see that we might
> have a problem of this sort if we accepted that patch --- but it seems
> Peter's not excited about that one either.

Given that the anum.h stuff is gone, "vastly" might be an
overstatement. I'm pretty surprised to find out that people don't
like the idea of having dependencies be correct from anywhere in the
tree. Even if I'm the only developer who does partial builds, the
cost seems to me to be next to nil, so I'm not quite sure what anyone
gets out of rejecting this patch. That having been said, it's not
really worth it to me to spend a lot of time arguing about it. So
far, the only coherent argument why this is bad is that it moves some
logic into a shared Makefile rather than a directory-specific
Makefile, which might be confusing to someone trying to maintain the
Makefiles. I don't really buy that because they're already complex
enough that you have to read them all to understand what they are
doing, and nothing in this quite small patch is going to change that
picture very much, but I guess that's just me.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-08-12 01:42:26 Re: WIP: getting rid of the pg_database flat file
Previous Message Robert Haas 2009-08-12 01:29:26 Re: pgindent timing (was Re: [COMMITTERS] pgsql: Refactor NUM_cache_remove calls in error report path to a PG_TRY)