From: | Bohdan Mart <mart(dot)bogdan(at)gmail(dot)com> |
---|---|
To: | Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, postgres(at)coyotebush(dot)net, john(dot)morris(at)crunchydata(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org, 'Bruce Momjian' <bruce(at)momjian(dot)us> |
Subject: | Re: Where can I find the doxyfile? |
Date: | 2023-10-09 15:14:05 |
Message-ID: | a0f6fb64-43b7-4963-a989-5a83b5db0c74@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 09.10.23 11:38, Stefan Kaltenbrunner wrote:
> I have not actually looked at the code of the filter itself but
> personally I'm not super happy with doing a C-based filter as part of
> our doxygen documentation generation step - that seems like an
> additional maintainance burden infrastrukcture wise - is there nothing
> more lightweight available(assuming we even want that)?
Hello, Stefan.
This indeed can require some maintenace, unfortunately. But I think it
is worth it! Please see screenshots in attachments. On the left there
are currently published doxygen, and on right is documentation I have
generated with John's config. (It doesn't show source, but I believe it
is discrepancy in config, not issue from filter).
There could be some false positive, like in this code:
/* Functions in access/index/amapi.c */
extern IndexAmRoutine *GetIndexAmRoutine(Oid amhandler);
extern IndexAmRoutine *GetIndexAmRoutineByAmId(Oid amoid, bool noerror);
Doxygen would concat `Functions in access/index/amapi.c` with actual
docs from .c file, and resulting docs would become:
> GetIndexAmRoutine - call the specified access method handler routine to get its IndexAmRoutine struct, which will be palloc'd in the caller's context.
>
> Functions in access/index/amapi.c.
>
> Note that if the amhandler function is built-in, this will not involve any catalog access. It's therefore safe to use this while bootstrapping indexes for the system catalogs. relcache.c relies on that.
>
> Definition at line 33 of file amapi.c.
But that's not big problem, IMHO. Better at least some docs misrendered,
than no comments in docs.
Other option would be to manually clean up documentation to provide more
concise comments. I can actually try doing it, few files at a time.
But that would damage git history and git-blame, unless we use
.git-blame-ignore-revs-entry
I have tested, and if we add such commit to ignoreblame, and don't
change actual line numbers, git-blame works fine.
So I have created draft patches(don't pay atention to commit message in
patch, it's just draft) with way, how this comemnts can be changed. It
can be done semi manually, with applying that filter by hands and then
commiting to git. I am willing to do that, if this option is preferable
over using filter during build process.
P.S. Editors, such as VsCode and CLion parses comments in any format and
show them as documentation, so if use standalone tool to view code
instead of Doxygen it is good experience. But having proper
documentation in Doxygen would help new people who haven't downloaded
code and configured IDE yet.
P.S. My original question was to have current doxygen config to be
published, like it was in 2008.
Regards,
Bohdan Mart.
Attachment | Content-Type | Size |
---|---|---|
gist_c.png | image/png | 564.1 KB |
createTempGistContext.png | image/png | 107.0 KB |
IndexAmRoutine.png | image/png | 379.4 KB |
0001-fix-documentation-style.patch | text/x-patch | 1.8 KB |
0002-add-git-blame-ignore-revs-entry.patch | text/x-patch | 778 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-10-09 15:48:50 | Re: pg_resetwal: Corrections around -c option |
Previous Message | Jelte Fennema | 2023-10-09 15:08:55 | Re: Request for comment on setting binary format output per session |