| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a CCompiler module for the giscanner Python scripts so that items
related to the run of the preprocessor, compiler and linker can be done in
this module, and this marks the beginning of the move of building the
introspection files using Python's distutils.
This patch first moves _add_[internal|external]_link_flags() to
ccompiler.py as get_[internal|external]_link_flags and also moves the
Windows shlibs resolution (deducing the DLLs the introspection files should
link to from the libraries passed in) in shlibs.py to
resolve_windows_libs() in ccompiler.py
https://bugzilla.gnome.org/show_bug.cgi?id=728313
|
|
|
|
|
|
|
| |
Conform shlibs.py to the PEP8 standard. New additions were causing make
check to fail:
Fixed E211 whitespace before '('
Fixed E501 line too long (104 > 99 characters)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit f3fcdf97 introduced shlib resolution for Windows, but it only works
with MinGW and would therefore break builds of introspection files for
Visual C++.
Improve on the situation by adding capabilities to do the same with Visual
C++, as the introspection dumper program is still compiled and linked with
the Microsoft tool set (only the proprocessor to process the various
headers is using GCC/MinGW).
This makes use of the dumpbin utility that is shipped with Visual C++,
which will query a .lib file, which leads to the DLL that the .lib file
will link to. The 'gcc -print-search-dirs' can be replaced on Visual C++
builds by querying the LIB environment variable, as this is what the Visual
C++ compiler/linker really looks at during compilation and linkage.
https://bugzilla.gnome.org/show_bug.cgi?id=724890
|
|
|
|
|
|
|
|
|
| |
GI just adds '.dll' to library name and calls it a day. There's a
comment about how this function might work, i've used it to implement
something better. This requires a compiler that supports
-print-search-dirs argument (i.e. gcc) and a dlltool.
https://bugzilla.gnome.org/show_bug.cgi?id=724890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Version in our tree is a wee bit outdated. For example,
later work will introduce an utf8 encoded python source
file which our old pep8.py does not yet understand (yeah,
it really was *that* ancient)...
Updated from:
https://raw.github.com/jcrocholl/pep8/1.4.5/pep8.py
Takes 552c1f1525e37a30376790151c1ba437776682c5,
f941537d1c0a40f0906490ed160db6c79af572d3,
5a4afe2a77d0ff7d9fea13dd93c3304a6ca993de and
a17f157e19bd6792c00321c8020dca5e5a281f45 into account...
https://bugzilla.gnome.org/show_bug.cgi?id=699535
|
|
|
|
|
|
|
| |
Commit 9a1e0c63c13f3567e75553d2d07dd914d5b81287 broke this as
os.name doesn't return 'OpenBSD', but 'posix'
https://bugzilla.gnome.org/show_bug.cgi?id=696765
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=688897
|
|
|
|
|
|
|
| |
os.uname is not available universally, so use something that exists
universally.
https://bugzilla.gnome.org/show_bug.cgi?id=681820
|
|
|
|
|
|
| |
situations. So adjust resolve_non_libtool() in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=664282
|
|
|
|
|
|
| |
By simply appending '.dll' to the library names.
https://bugzilla.gnome.org/show_bug.cgi?id=620566
|
| |
|
| |
|
|
|
|
|
| |
Let us know explicitly if the platform is unsupported by
the scanner.
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=606686
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to the current --library=<foo>, support --library=lib<foo>.la.
This makes it unambiguous that we are referencing an uninstalled
library and allows accurate extraction of the shared library name
for the uninstalled library.
* tests/scanner/Makefile.am tests/offsets/Makefile.am: Use the
new form of --library=. Also some LD_LIBRARY_PATH frobbing as needed.
*-expected.gir *-expected.tgir: We now pick out the shared library
accurately, so fix shared-library="" in our reference girs. (The
comparison may need some pre-sanitization now to work on non-ELF)
http://bugzilla.gnome.org/show_bug.cgi?id=591669
|
|
Using ctypes.util.find_library() to resolve library names to
sonames causes problems with dealing with uninstalled libtool
operation properly. We're unlikely to find any way of combining
the two that will be robust against future changes in both
facilities.
Switch to a different approach - run 'ldd' on the compiled
introspection binary and extract sonames from there This is
less portable but should be quite robust where it works.
utils.py dumper.py: Move libtool-command-line finding into utils.py
girwriter.py: Remove library name resolution from here, expect libraries
to be passed in preresolved.
shlibs.py scannermain.py: New file including resolve_shlibs() to resolve
library names using the introspection binary.
tests/scanner/Makefile.am: Add .libs to LD_LIBRARY_PATH
http://bugzilla.gnome.org/show_bug.cgi?id=591669
|