Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

parser: Add doc format support #1641

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

bilelmoussaoui
Copy link
Member

Replaces the current use_gi_docgen key

We would need gtk-rs/gir-files#237 to land first but that is blocked on more core libraries defining the doc:format properly.

@bilelmoussaoui
Copy link
Member Author

Obviously this was untested, so please don't merge.

@@ -138,7 +140,7 @@ fn replace_symbols(
env: &Env,
in_type: Option<(&TypeId, Option<LocationInObject>)>,
) -> String {
if env.config.use_gi_docgen {
if env.library.doc_format == DocFormat::GiDocgen {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps for now this could be a if library.doc_format == DocFormat::GiDocgen || config.use_gi_docgen for the moment.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that is an option yes, although, it will end up staying there given no one will remember to remove it. As this option only impacts docs generation, i rather have bindings manually amend the format into the gir file then gir keeping this old "hack"

Copy link
Contributor

@A6GibKm A6GibKm Mar 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My fear is that this is a bit of a chicken and egg situation. Breaking gir generation is a discouragement for setting doc_format and this MR depends on libraries using it.

I suppose an alternative is to have a prequel for this PR that just reads the doc_format and does nothing with it (instead of crashing) to unblock the situation, such a MR would not depend on gir-files.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is always been like that when it comes to new annotations so i rather fix things properly.

@A6GibKm
Copy link
Contributor

A6GibKm commented Mar 10, 2025

Please link https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/401 in the commit message.

@@ -336,7 +335,7 @@ status = "generate"
name = "stock_list_ids"
# allows to ignore global functions
ignore = true
# allows to define if the function was moved to a trait
# allows to define if the function was moved to a trait
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These could go in a separate commit.

GtkDocMarkdown,
GtkDocDocbook,
GiDocgen,
HotDoc,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be Hotdoc if the key is not hot-doc.

@@ -14,7 +14,6 @@ target_path = "."
# auto_path = "src/auto"
work_mode = "normal"
# Whether the library uses https://gitlab.gnome.org/GNOME/gi-docgen for its documentation
use_gi_docgen = false
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's going to take a while until everything uses this so for the time being maybe change use_gi_docgen to doc_format and allow the same values there, and don't make the attribute in the XML mandatory yet?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is everything? It is GTK, GLib, Pango and libadwaita (merged already https://gitlab.gnome.org/GNOME/libadwaita/-/merge_requests/1428).

The remaining bindings don't get updated often at all.

If you just want to ignore the element for now, it could be done in a separate patch by someone else.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If everything using gi-docgen is updated then that's fine with me. Just default to "unknown" if the attribute is not in the XML.

@werdahias
Copy link

werdahias commented Mar 11, 2025

I built gir 0.20.5 with this MR added as patch; though I still get the Unexpected element " error.
Any ideas as to why ? This is with glib 2.84.0 as testcase

@bilelmoussaoui
Copy link
Member Author

Did the changes to ignore the attribute in #1645, other changes could be done separately later to not block other packages forever & we can backport it easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update for gobject-introspection 1.83's new doc:format element
4 participants