548ec9f186 accidentally moved the GVariant
spec to the toplevel /usr/share/doc directory, which is surely not
right. Let's move it back into the glib-2.0 subdirectory.
It's debatable whether this is the best place to install the GVariant
specification, since it's not part of the gi-docgen docs, but surely
it's much better than not putting it in any subdirectory.
Fixes#3351
The `gi-docgen` tool is not designed to be used like that. In
particular, when nesting documentation directories, the generated
`*.devhelp2` files (needed by Devhelp to show the documentation) are
nested one directory level too deep for Devhelp to find them, and hence
are useless, and the documentation doesn’t show up in this common
documentation viewer.
So, change the installed documentation directory hierarchy:
* `${PREFIX}/share/doc/glib-2.0/gio` → `${PREFIX}/share/doc/gio-2.0`
* `${PREFIX}/share/doc/glib-2.0/glib-unix` →
`${PREFIX}/share/doc/glib-unix-2.0`
* `${PREFIX}/share/doc/glib-2.0/gobject` →
`${PREFIX}/share/doc/gobject-2.0`
* etc.
* `${PREFIX}/share/doc/glib-2.0/glib` → `${PREFIX}/share/doc/glib-2.0`
This is going to seem like pointless churn (the contents of the
documentation have not changed), and packagers may mourn the split of
content in `/usr/share/doc` from `/usr/share/doc/${package_name}` to
`/usr/share/doc/${pkg_config_id}` instead, but that seems to be the best
approach to fix this issue in GLib. gi-docgen’s behaviour does feel
fairly consistent and correct with the rest of how it works (single
output directory).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3287
This is nowhere near a complete check-through and gi-docgenification of
the signals docs, just a few bits I was looking at anyway.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
We install gvariant-specification-1.0.html to `docs_dir` but that shouldn't require `enable_gir`.
Fixes: docs/reference/glib/meson.build:26:16: ERROR: Unknown variable "docs_dir"
Part-of: <https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3955>
gi-compile-repository --module and gi-decompile-typelib --shlib are
intentionally undocumented here: they will be removed in !3926.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is a behaviour change from g-ir-generate, which treats it as
least-important-first (the last directory on the command-line is
searched first).
gi-compile-repository --includedir and gcc -I are most-important-first
(the first directory on the command-line is searched first) so it seems
like it makes most sense to be consistent with that.
Signed-off-by: Simon McVittie <smcv@collabora.com>
So now introspection users will have to call `GLibUnix.open_pipe()`
rather than `GLibUnix.unix_open_pipe()` — or
`GLibWin32.check_windows_version()` rather than
`GLibWin32.win32_check_windows_version()`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
This should clarify things a little for users of language bindings, who
don’t directly use `.pc` files.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This creates `GioUnix`, `GioWin32`, `GLibUnix` and `GLibWin32`. These
bodies of documentation are in addition to the main, platform agnostic,
documentation for both libraries.
This commit necessarily includes various mechanical changes to update
the repository namespace used in various existing documentation links to
platform specific APIs.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Seems no point in keeping them separate. It doesn’t seem to matter if
they contain entries which are unused for a particular docs build.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
`--version` is conventionally used to find the version of the program
itself. While that’s not currently implemented in
`gi-inspect-repository`, let’s not box ourselves into a corner.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Eventually, we want to move to using `GType` directly for everything,
since `GIBaseInfo` and its subclasses are all using `GTypeInstance`.
However, that requires quite a lot of changes and we’re about to hit the
API freeze.
So do the smallest set of changes possible to remove `GIInfoType` and
related functions from the public API, which gives us freedom to make
more changes later without breaking API.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
It’s actually a factory method rather than a constructor, since
`GIBaseInfo` is abstract, but despite that, changing the name so it sits
inside the `GIBaseInfo` class makes sense. There is no `GIInfo` type.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Since `GITypelib` is exposed in the public libgirepository API, it needs
to be a boxed type. So we either need to add a `copy` method to mirror
the existing `free` method, or switch to refcounting. The latter option
seems better, since a `GITypelib` contains internal state about open
`GModule`s and the semantics for copying that would be potentially
complex.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This makes them consistent with the other getter methods in
`GIRepository` which return lists/arrays. It’s useful to return the
length, as that means the caller doesn’t have to work it out by
iterating over the entire array.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Otherwise we would generate a multiple-inclusion guard of the
form `#ifndef __STDOUT__ ...`, which can only work for one D-Bus
interface per translation unit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're writing the body to standard output, we cannot know what the
filename of the corresponding header is going to be, but it seems
vanishingly unlikely that it will be either `stdout.h` (which we would
traditionally have generated) or `-.h` (which we would have generated
since !3886).
This makes some of the output snippets sufficiently short that black(1)
requires that they are folded into a single line.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise there’s no obvious suitable return value to return when the
union is *not* discriminated.
This is an API break, but libgirepository has not been in a stable
release yet, so that’s fine.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
Fix the declaration and documentation of
`gi_object_info_find_method_using_interfaces()` and
`gi_object_info_find_vfunc_using_interfaces()`. The documentation was
wrong when I wrote it: the value returned is the object or interface
which declares the method or vfunc, not the one which implements it.
The returned declarer info may be a `GIObjectInfo` or a
`GIInterfaceInfo`. Since those two types have no subtype relation
between them, the return type has to be changed to `GIBaseInfo`. Using
`GIObjectInfo` would have been fine in girepository-1.0 because all
`*Info` types were aliases of each other — but since the move to
`GTypeInstance` this is no longer true.
A unit test will be in the following commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3246
This covers all the API changes from girepository-1.0 to
girepository-2.0 so far.
It was generated by manually looking through the changes in `git diff
af36393e6.. -- girepository/*.h`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3155
This might help increase visibility of Philip's useful GMainContext
tutorial. Although the GMainContext documentation is fairly good, it's
also pretty intimidating. The tutorial is very useful and provides
guidance that we can't fit directly into the documentation, so reference
it.
