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>
This should make the code a bit more usable in situations where people
aren’t potentially using MSVC.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3255
`GITypeInfo` isn’t defined in `libgirepository-internals`, and that was
forcing us to do some header includes which violated the layering
between `libigrepository-internals` and `libgirepository`. Fix that by
moving the helper function to the header/source where `GITypeInfo` is
defined.
This fixes commit 54f156bd63.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
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>
The positional parameters are declared as G_OPTION_ARG_FILENAME_ARRAY,
but only the first one is used.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This seems to have been a remnant of support for embedding the typelib
in the shared library, which was removed from this tool in commit 4bf5ef6b
"[girepository] Actually verify header of loaded typelibs in
g_irepository_require" (originally gobject-introspection@05ffd857).
The feature of embedding the typelib in a shared library was itself
removed in commit b2df59c3 "compiler: Remove --code argument",
originally gobject-introspection@ac81f3e8, with a note that because
we rely on being able to load the shared library into g-ir-scanner,
anything that links g-ir-scanner output into the shared library would be
a circular dependency.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It seems cleaner to store this in the parser, rather than having the
compiler export a global variable that the parser must read.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This hasn't actually done anything since commit 45a04358
"[gircompiler] Clean up parsing" (originally
gobject-introspection@8942500c).
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>
