The current output (more or less a straight copy of the wiki) is available
here:
https://gi.readthedocs.io
This contains two changes:
* Converts all (not completely outdated) wiki pages to a sphinx based
documentation.
* Converts the man pages to reST and adds a Makefile for building them
using rst2man. So they can be easily exposed in the sphinx docs.
Goals:
* Have a user focused/compact documentation instead of random wiki pages
with various todo/ideas pages.
* Take advantage of the gitlab MR workflow by
* allowing large documentation changes/refactorings with reviews
* allowing to combine features changes with documentation changes in MRs
The "--code" option was removed years ago in ac81f3e8c5f1c380d16677232d67466e739da283
so remove references to it from README and g-ir-compiler(1)
Remove the "--no-init" option from g-ir-compiler and g-ir-compiler(1)
as it was documented to "can only be used if --code is also specified",
so no reason to keep it around.
2008-08-29 Johan Dahlin <johan@gnome.org>
* Makefile.am:
* docs/g-ir-compiler.1:
* docs/g-ir-generate.1:
* docs/g-ir-scanner.1:
Add man pages for the generator and compiler.
svn path=/trunk/; revision=518
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>
We certainly won't find the requested namespace in a newly-created
repository with no typelibs loaded.
Fixes: 9ab84bc1 "girwriter: Stop using the singleton GIRepository"
Signed-off-by: Simon McVittie <smcv@collabora.com>
Deriving from two templates means the `before_script` from the second
one overrides, rather than adding to, the one from the first.
Avoid that when using `.build-linux` and `.with-git` by explicitly
joining both scripts.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
On i386 Linux, the minimal ABI alignment of a double is only 4, and
therefore the alignment of GDoubleIEEE754 is also 4.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It's helpful for the assertion message to say what we were expecting and
what we actually got. It's also useful to have g_test_message()
diagnostics to indicate how far into the test we were.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we didn't test these at all, which made it hard to determine
whether %Ec, %EC had appropriate output on platforms where era-based
dates are unsupported. Now we do, and we can observe that on platforms
with no support for era-based dates, %c matches %Ec and %C matches %EC,
as desired.
Signed-off-by: Simon McVittie <smcv@collabora.com>
I can't read Japanese, but these match the output of:
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%c' | iconv -f eucjp -t UTF-8
env TZ=UTC LC_ALL=ja_JP.eucjp date -d2009-10-24T00:00:00Z '+%C' | iconv -f eucjp -t UTF-8
which seem like a reasonable thing to use as a reference.
According to Google Translate, 平成 refers to the Heisei era, which was
current during 2009, and seems unreasonable to expect as output on a
platform where era-based dates are unsupported.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/3252
Signed-off-by: Simon McVittie <smcv@collabora.com>
On a fast laptop, this test currently takes about 7s to run, which is a
significant portion of the overall test suite time.
On a slower CI machine, especially running the test under valgrind, the
test can time out.
There’s no need to always run so many iterations: we run the tests under
CI so often that it’s likely a failure will eventually be hit (if there
is a bug) even with fewer iterations. We also now run the tests once a
week with `-m slow`, so the original iteration count will also still be
used then.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
To avoid a big introspection API break.
These APIs are now listed in the new `{GLib,Gio}{Unix,Win32}-2.0.gir`
files, but for backwards compatibility they need to continue to be
listed in `Gio-2.0.gir` and `GLib-2.0.gir` as well, until the next major
introspection API break (and none is planned).
No new platform specific APIs should be added to these GIR files, but
these existing ones must remain.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3892#note_2001361
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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
Enable the msys2-mingw32 CI job for merges, just like the fedora-x86_64
job is. The pair of them can then build the platform specific GIR and
documentation files.
The `download-reference.sh` script in the `docs-gtk-org` branch of GTK
can then download the docs as an artifact from the latest GLib build of
`main`, and publish them on docs.gtk.org, as is currently done for the
platform agnostic documentation.
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
For both GLib and GIO. (GObject, GIRepository and GModule don’t have any
platform specific APIs.)
This is needed for two reasons:
* If the same GIR file is shipped on multiple platforms, it has no way
to conditionally define/not-define an API based on the platform (like
an `#ifdef` in a C header). So we either end up shipping differing
GIR APIs on different platforms, or shipping a GIR file which
declares APIs which aren’t resolvable by `dlopen()` on certain
platforms, and will cause a language runtime error.
* The API reference documentation is now generated from the GIR, and
similar problems are present there: if the GIR contains different
symbols depending on the platform, there is no way to generate API
documentation for the union of all of them.
The fix is to ensure that there are no conditional symbols in a GIR, by
splitting out the platform specific symbols into platform specific GIR
files. Platform specific documentation can then be generated from these,
in addition to the main, platform agnostic, documentation.
The documentation changes will following in a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
Maintain them in separate lists within `meson.build`. This makes no
functional difference at the moment, but will be used in an upcoming
commit to generate separate GIR files per platform.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
There was no obvious logical need to list the `GAppInfo` subclass
sources separately in the build. It makes more sense to add them to the
platform-specific source lists, since they are platform specific.
This will be used in an upcoming commit which generates
platform-specific GIR files, so needs the full platform-specific lists
of sources.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
