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

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Feb 7, 2014 at 7:39 AM, Christian Convey
> <christian(dot)convey(at)gmail(dot)com> wrote:
>> 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.

Aside from Robert's points, I have a couple of thoughts:

I think if it had been a clear, enforced goal all along, it might've been
possible to build the system with such a restriction (for the most part at
least). At this point though, the amount of work and code churn involved
seems like it'd far exceed the benefits.

It's also fair to question how much improvement in comprehensibility
we'd really get. It's not like code's been dropped into completely
random places where it doesn't belong. In the end, Postgres is a pretty
big system and it's necessarily going to take time for newbies to learn
their way around it.

I believe there are some cases where circularity is just about
unavoidable. As an example, the error reporting code in elog.c depends
on memory management in mcxt.c, which itself uses elog.c's reporting
facilities. There's another mutual dependency between error reporting
and GUC (server configuration control). And on and on. I think the
coding rule you're suggesting would require that each such dependency
loop be confined to one major backend subsystem, which seems rather
arbitrary.

regards, tom lane