Re: [COMMITTERS] pgsql: Clean up the #include mess a little.
От | Alvaro Herrera |
---|---|
Тема | Re: [COMMITTERS] pgsql: Clean up the #include mess a little. |
Дата | |
Msg-id | 1315336362-sup-5301@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Clean up the #include mess a little. (Ants Aasma <ants.aasma@eesti.ee>) |
Ответы |
Re: [COMMITTERS] pgsql: Clean up the #include mess a little.
|
Список | pgsql-hackers |
Excerpts from Ants Aasma's message of mar sep 06 12:40:04 -0300 2011: > On Mon, Sep 5, 2011 at 4:55 PM, Greg Stark <stark@mit.edu> wrote: > > What I wouldn't mind seeing is a graph of all includes and what they > > include. This might help figure out what layering violations there are > > like the one that caused this mess. I think I've seen tools to do this > > already somewhere. > > I whipped together a quick Python script to do this. Attached is the > Python script (requires pydot) and the result of running it on includes/. > I didn't attach the png version of the output because it was 7MB. > > If rendering all includes at once doesn't give a good overview it can > also select a subset through traversing dependencies. For example: > render_includes.py -i include/ \ > --select="storage/spin.h+*,access/xlog.h+*" output.png > > This will render everything that directly or indirectly depends on those > two headers. See --help for details. Wow, interesting, thanks. What this says to me is that we should do something about execnodes.h and some other nodes file (parsenodes.h I think). I wonder what happens if files in the same subdir are grouped in a subgraph. Is that possible? -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: