Re: Breaking compile-time dependency cycles of Postgres subdirs?

On Fri, Feb 7, 2014 at 7:39 AM, Christian Convey
<christian.convey@gmail.com> wrote:
> This question is mostly just curiosity...
>
> There are build-time dependency cycles between some of Postgres' code
> subdirectories.  For example, "storage" and "access" have such a cycle:
> storage/buffpage.h #includes access/xlogdefs.h
> access/visibilitymap.h #includes storage/block.h
>
> Has there been any discussion about reorganizing these directories so that
> no such cycles exist?

Not to my knowledge.

> As someone very new to this code base, I think these cycles make it a little
> harder to figure out the runtime and compile-time dependencies between the
> subsystems these directories seem to represent.  I wonder if that's a
> problem others face as well?

There are probably some cases that could be improved, but I have my
doubts about whether eliminating cycles is a reasonable goal.
Sometimes, two modules really do depend on each other.  And, you're
talking about this not just on the level of individual files but
entire subtrees.  There are 90,000 lines of code in src/backend/access
(whose headers are in src/include/access) and more than 38,000 in
src/backend/storage (whose headers are in src/include/storage);
expecting all dependencies between those modules to go in one
direction doesn't feel terribly reasonable.  If it could be done at
all, you'd probably end up separating code into lots of little tiny
directories, splitting apart modules with logically related
functionality into chunks living in entirely different parts of the
source tree - and I don't think that would be an improvement.

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