| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
This is an initial test before we port over to docbook to see if we
can build a new structure for how the pages should act.
|
|
|
|
|
| |
These will eventually be paired with the sections file parser to create
a set of sections.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While gobject-introspection works on OS X, a few circumstances are
handled a little different there. For one, libraries are linked using
absolute paths. The current gobject-introspection code however strips
any path components and just uses the filename in the .gir file –
while this doesn't cause failure, the generated typlibs will only work
in presence of a correctly set DYLD_LIBRARY_PATH or
DYLD_FALLBACK_LIBRARY_PATH environment variable.
Setting DYLD_LIBRARY_PATH on OS X often is a bad idea due to the
side-effects: Doing so causes the directory parts of libraries
referenced using an absolute path to be ignored if there is a equally
named file in the directory listed in $DYLD_LIBRARY_PATH, possibly
overriding referenced system libraries with incompatible versions.
Setting DYLD_FALLBACK_LIBRARY_PATH is the better solution for this
problem; however because this variable has an implicit default value
it's not simple to do so correctly.
The best solution to the problem is referencing libraries from .girs
using absolute paths, just as all other binaries on OS X. The attached
patches against 2.38.0 implement that.
Another quirk one needs to be aware of on OS X is that Apple ships a
program called libtool, which is not GNU libtool and incompatible with
it. GNU libtool, if present, is usually called glibtool on OS X. The
patches also fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=709583
|
|
|
|
|
|
| |
Improves support on MacOS when scanning system headers.
https://bugzilla.gnome.org/show_bug.cgi?id=631507
|
|
|
|
|
| |
This prevents fields like __gtk_reserved1 from being emitted in the
documentation.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove GInitiallyUnowned special case in gdumpparser where fields are
copied from GObject. Add generic solution where anytime we have multiple
typedef structs, the fields become shared:
typedef struct _Foo Foo;
typedef struct _Foo Bar;
struct _Foo {...};
https://bugzilla.gnome.org/show_bug.cgi?id=581525
|
|
|
|
|
|
|
|
|
| |
Move exception handling of various symbol/identifier stripping into the
outer level parse function. This removes a lot of embedded try excepts
peppered throughout the code by letting exceptions flow to the top level
where they can be handled just as gracefully.
https://bugzilla.gnome.org/show_bug.cgi?id=581525
|
|
|
|
|
|
|
|
|
| |
Remove the caching of typedefs in Transformer._typedef_ns. This is no longer
used due to the added _tag_ns cache which store tags rather than typedefs.
Remove adding of callback typdefs to the typedef_ns since these were not
being used anyhow.
https://bugzilla.gnome.org/show_bug.cgi?id=581525
|
|
|
|
|
|
|
| |
Generalize _create_tag_ns_struct for both structs and unions. Remove
_create_compound newer struct parsing code has completely replaced it.
https://bugzilla.gnome.org/show_bug.cgi?id=581525
|
|
|
|
|
|
|
|
| |
Add _create_member_struct for the parsing of nested structs. This is
precursory work to remove the member/anonymous flag from other struct/union
creation code and allow simplification of those code paths.
https://bugzilla.gnome.org/show_bug.cgi?id=581525
|
|
|
|
|
|
|
|
|
| |
Add structs parsed from C's "tag namespace" into their own cache for lookup
by typdef parsing. This fixes issues where a typedef declared after a
struct would not have a correct name. This also cleans up the need for
special casing struct tags prefixed with an underscore.
https://bugzilla.gnome.org/show_bug.cgi?id=581525
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use g_slist_copy prior to returning the lists run through g_slist_reverse.
This preserves the source scanners internally held lists where previously
they would only point to a single element after a call, leaking memory and
breaking subsequent calls. Note the functions as (transfer container) and
use g_slist_free after calls in the Python bindings.
Add new unittest file: test_sourcescanner.py for isolated unittesting of the
SourceScanner.
https://bugzilla.gnome.org/show_bug.cgi?id=581525
|
|
|
|
|
|
|
| |
In all of the places that we pass through the CFLAGS, we should be doing
the same with the CPPFLAGS.
https://bugzilla.gnome.org/show_bug.cgi?id=720063
|
|
|
|
| |
It's possible for scanner->current_file to be NULL, so add a check...
|
|
|
|
|
|
|
|
| |
If $(CC) is unset, use 'cc' instead of 'gcc' as the default compiler.
This matches the behaviour used in the source scanner.
https://bugzilla.gnome.org/show_bug.cgi?id=720066
|
|
|
|
|
|
|
|
| |
When doing the source scanning in giscanner, make sure we pass the
user's CFLAGS environment variable to the compiler, as we do for the
dumper.
https://bugzilla.gnome.org/show_bug.cgi?id=720063
|
|
|
|
|
|
|
|
| |
Aliasing TRUE or FALSE is not very common, but done occasionally
for extra clarity. Namely G_SOURCE_REMOVE / G_SOURCE_CONTINUE are
self-explanatory, unlike the "raw" booleans.
https://bugzilla.gnome.org/show_bug.cgi?id=719566
|
|
|
|
|
|
| |
Otherwise we can overflow the stack on longer pathnames.
Tested-By: Mantas Mikulėnas <grawity@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
In this case we were considering -I and the path as two different
command line options. This was not a problem in the past (or for other
cpp flags) because they are passed directly to gcc that accepts it. Now
that we are ensuring that the include paths are always real paths, we
need to handle this case to identify include paths in the command line.
https://bugzilla.gnome.org/show_bug.cgi?id=712211
|
|
|
|
|
|
|
|
| |
Ensure we are using the real path also for cflags comming from
pkg_config files and command line options. This fixes the generation of
the gir files when include paths contain symlinks.
https://bugzilla.gnome.org/show_bug.cgi?id=712211
|
|
|
|
|
|
|
|
|
| |
path
This fixes the case when the include path doesn't contain any symlink,
but the path built by the preprocessor does.
https://bugzilla.gnome.org/show_bug.cgi?id=712211
|
|
|
|
|
|
|
|
| |
I'd like to be able to use this inside GTK+.
See: https://bugzilla.gnome.org/show_bug.cgi?id=711153
https://bugzilla.gnome.org/show_bug.cgi?id=711157
|
|
|
|
| |
Related to: https://bugzilla.gnome.org/show_bug.cgi?id=710561
|
|
|
|
|
|
| |
Structure field documentation was not being included in the gir file.
https://bugzilla.gnome.org/show_bug.cgi?id=710562
|
|
|
|
|
|
|
|
| |
A hidden exception was being thrown (which we now log), due to fields
being treated as function parameters. Fixed to make field array
annotations be transformed and written out to the gir correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=710561
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=710560
|
|
|
|
|
|
|
|
|
| |
When scanning for macros respect ifdefs of __GI_SCANNER__
in the various header files. Only #ifdef and #ifndef are supported.
If __GI_SCANNER__ appears in plain #if statements, a warning is
printed.
https://bugzilla.gnome.org/show_bug.cgi?id=698367
|
|
|
|
|
|
|
|
|
|
|
| |
giscannermodule expects file names to be canonicalized and
symlinks to be resolved (most likely to support users of
symlinked /usr/local). Instead of computing absolute and real
paths all over the place, we can do this once on entry
in SourceScanner().parse_files() and SourceScanner().parse_macros()
and clean the rest a bit...
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Was looking around a bit and noticed about 2/3 of
g-ir-scanner time is spent in SourceScanner().parse_files().
Some profiling quickly shows most of that 2/3 is used
by gi_source_scanner_add_symbol() where it creates a whole
bunch of GFile instances just to compare paths and throw
them away again. With this a scanner instance now maintains
a hash table of GFile instances instead of a list of file
names, so comparing those paths can be reduced to a fast
g_hash_table_contains() call.
This makes "g-ir-scanner <whole_bunch_of_options> --output Gtk-3.0.gir"
complete in about 10 seconds on my box instead of about
30 seconds (both best of 3 runs).
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
|
|
|
| |
This was broken in 0d6db7114a176c2d24a19a2d6a570aab406608ac
where the unescaped filename was still computed but
no longer used...
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
|
|
| |
This reverts commit 77fcc8fa47d63f58b2c3f6216a0493e42f6d44b3.
Will be not needed in about 2 patches...
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
|
|
|
|
| |
This reverts commit 8c0ca4717d834a6c578579656683c55ea22a06f4.
The "fast" path doesn't seem to work at all. Testing shows creating
Gtk-3.0.gir still takes about 30 seconds with this (even on
a Linux box)...
https://bugzilla.gnome.org/show_bug.cgi?id=710320
|
|
|
|
|
| |
They should be treated the same as regular volatile specifiers,
not like __attribute__() or __asm__().
|
|
|
|
|
|
| |
Going through the VFS layer is substantially slower, so check against
the base filenames first. This speeds things up on case-sensitive
filesystems.
|
|
|
|
| |
We already know the condition will be TRUE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's no sense in keeping it around as it is never
used. And even though measuring the time it takes to
build Gtk-3.0.gir using a) the C version and b) the
Python version reveals there is no measurable difference
to speak of (when *not* running under Python's cProfile
module):
With C collect_attributes:
==========================
real 0m30.614s
real 0m32.255s
real 0m31.034s
With Python collect_attributes:
===============================
real 0m31.530s
real 0m31.549s
real 0m31.673s
The C version ends up using g_markup_escape_text() which
will escape \004 as . Even though this is invalid
xml 1.0 (but valid xml 1.1), the Python version leaves
the \004 as is, which is even less desirable...
|
|
|
|
|
|
| |
_write_class() is only ever called with ast.Class
and ast.Interface nodes so the check served no purpose
other than contribute to global warming...
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When encountering /**/ in the source, parse_gtk_doc_comment()
would be executed (due to the /** part starting a GTK-Doc
comment block) and would happily consume the / and everything
up until the next comment block was closed or EOF, thus
consuming a whole block of C code...
Encoutered in the wild here:
https://git.gnome.org/browse/clutter-gst/tree/clutter-gst/clutter-gst-player.c?id=03f0d8f48bd7f60e582e6185cb73a07038e8d55d#n1926
|
|
|
|
|
|
| |
Makes our GTK-Doc comment block rewriting tool halt on
such issues, requireing user intervention instead of writing
back even more bogus data.
|
| |
|
|
|
|
|
|
| |
annotationparser.py already stores attributes in a mapping so
it makes little sense using a list of tuples (suggesting
multiple duplicate keys would be allowed) on the ast side.
|
|
|
|
|
| |
makes _parse_annotations() and _parse_fields() callers slightly
more readable
|
|
|
|
|
| |
... so it points to the start of the GTK-Doc comment
block instead of the position of the identifier field.
|
|
|
|
| |
tests/warn/unkown-parameter.h:41 still passes with this...
|
| |
|
|
|
|
|
|
|
| |
GTK-Doc comment block fixer tool will refuse to rewrite source
files that generated errors (indicating a source->parse tree->source
would result in information being lost), but will happily continue
on warnings (which do not result in information being lost).
|
| |
|
|
|
|
|
|
|
|
|
| |
GTK-Doc parameter description fields are allowed to span
multiple lines, tag description fields are allowed to span
multiple lines and paragraphs. A tool fixing/rewriting
GTK-Doc comment blocks in source files would need to have
description fields parsed and stored (almost) exactly as
they appear in the source file.
|