| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing code tries to mirror how the linker finds DLLs by
searching for the import libs and then looking for the matching
shared lib name.
While llvm has a dlltool clone it doesn't provide the --identify
option to extract the shared lib name. Instead we use the fact that
llvm import libs include the dll name in the archive member name, so
we can use "nm" there to get the same result.
To decide which strategy to use we run dlltool and check if it contains
"llvm-dlltool" in the output.
This fixes the .gir and .typelib files containing bogus values for the
shared library names when building with clang + mingw-w64 on Windows.
I'm not quite sure if the libtool part is actually needed there,
but I left it in to keep the diff small.
|
| |
|
|
|
|
|
| |
While gcc on Windows allows being passed -rpath and just ignores it,
llvm/lld will fail with "lld: error: unknown argument: -rpath".
There is no such thing as rpath on Windows, so just skip it.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We currently use the `CC` environment variable to find the C compiler to
use internally in g-ir-scanner. Build systems might wish to store the
compiler detected during the build configuration, and then pass that
compiler to g-ir-scanner at the time of build, avoiding to put things
into the environment.
One possible solution is to have a command line argument that lets us
specify the C compiler, with the same semantics as the `CC` environment
variable.
|
| |
|
|
|
|
|
|
| |
Otherwise we'll end up using the locale encoding. While it's usually utf-8,
that's not the case on Windows.
There is one place where a file with filenames is passed, not sure there
so I left it and passed a explicit None.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds quick support for using 'clang-cl' (CLang's emulation of the Visual
Studio compiler) to run giscanner.
This will still initialize things mostly in the MSVC fashion, except that it
will also check whether both 'CC' and 'CXX' envvars are set to
'clang-cl [args]', as per the way that Meson supports using 'clang-cl'.
Since we are using distutils to set up the compiler instance, when we enable
'clang-cl' support, we trick distutils that we have already initialized the
MSVCCompiler parameters as needed. We just leave out the compiler flags as
we don't really care about debug symbols nor optimization with the built
dumper binary, as it is gone as soon as the .gir file is generated.
This will build G-I successfully with all the tests passed.
|
| |
|
|
|
|
|
|
|
|
| |
By default LD_LIBRARY_PATH is set to the list of target library paths;
this breaks down in cross-compilation environment, as we need to run a
native emulation wrapper rather than the target binary itself. This patch
allows exporting those paths to a different environment variable
which can be picked up and used by the wrapper.
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When we save the macros to pass to distutils to compile the dumper
program, the quotes were not properly preserved for Visual Studio
builds, causing items such as -DG_LOG_DOMAIN to fail as quotes are used
in there.
When we use quotes in macro definitions, we escape the escape
character in ccompiler._set_cpp_options() when we are running
g-ir-scanner with Visual Studio, so that distutils won't be too eager
to drop those prematurely.
|
| |
|
|
|
| |
No need to hardcode things since distutils looks it up.
Similar to !170 but for Windows.
|
| |
|
|
|
|
|
|
|
| |
The original customize_compiler() calls into _osx_support.customize_compiler()
the first time it is used and I didn't copy it in !118 because it is private API.
Issue #268 points out that the macOS build is broken now so I guess that was important
in some way. Make sure the setup code is run by calling the original customize_compiler()
with a dummy compiler instance.
|
| |
|
|
|
|
|
|
| |
Otherwise when you set CC=clang then distuils will still use gcc for linking.
While it seems we don't invoke the link command atm this shouldn't hurt.
The upstream customize_compiler() does the same thing on macOS and there is a bug
for enabling it everywhere: https://bugs.python.org/issue24935
|
| |
|
|
|
|
|
| |
Only use flags provided by env vars from the user and never from the
Python sysconfig. The sysconfig values depend on the way Python was built,
might conflict when using g-i with a different compiler and can't be controlled
by the g-i user.
|
| |
|
|
|
|
|
|
| |
So we have more control over it.
This also removes all macOS specific bits from it because I'm not sure if they are
needed and they depend in internal API. This means this change can cause functional
changes. Please report if you hit any!
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No functional changes intended.
Tests check that:
* Compiler is obtained from CC.
* cc is used as the default compiler.
Currently not true as a Python build time compiler is used as the default.
* Preprocessor is obtained from CC when CPP is unspecified by adding -E.
* Preprocessor is obtained from CPP.
* cpp is used as the default preprocessor.
Currently not true as Python build time preprocessor is used as the default.
* Shell word splitting rules are used to split CC.
* Shell word splitting rules are used to split CPP.
* Deprecation warnings are disabled during compilation.
* Preprocessing step includes CPPFLAGS.
* Compilation step includes both CFLAGS and CPPFLAGS, in that order.
* Macros from CFLAGS are defined only once.
Currently not true as they are defined twice.
* Flags that would retain macros after preprocessing step are filtered out.
Currently only partially true as they aren't filtered out from CPPFLAGS.
* Preprocessing step includes flag that preserves comments.
* Preprocessing step includes current working directory.
* Complete preprocessing command doesn't contain anything unexpected.
Currently not true as Python build time CPPFLAGS are included as well.
* Complete build command doesn't contain anything unexpected.
Currently not true as Python build time CFLAGS and CPPFLAGS are included as well.
|
| |
|
|
| |
We only support 3.4+ now.
|
| |
|
|
|
| |
This makes it easier to ensure that the right library is
scanned.
|
| |
|
|
|
| |
Without this, it will probably take the system library instead of the
one that we are trying to test.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
g-i includes an old version of pep8 and pyflakes and uses that
during "make check".
It (1) doesn't catch all cases newer versions of pycodestyle/pyflakes catch
and (2) doesn't test all Python files (3) doesn't work with meson.
Instead of updating just remove them and depend on flake8 instead.
To run the checks simply run flake8 in the root dir.
This also makes it possible to run those checks when using meson and
not autotools.
To not get test suite failures on flake8 updates move the checks from
"make check" to an extra "make check.quality" target.
|
| |
|
|
| |
as was pointed out in !12
|
| |
|
|
| |
Closes https://gitlab.gnome.org/GNOME/gobject-introspection/issues/205
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
command line arguments."
A very old version of MSYS performed normalization during path conversion
so "/bin/sh ../../libtool" became "c:/opt/msys/1.0/bin/libtool" ("sh .."
was considered a single folder), it doesn't do this any more; nor does
MSYS2.
Also, the old comment was incorrect. It claimed:
"This continues to reuse the LIBTOOL variable from automake if it's set,
but works around some MSYS weirdness: When running g-ir-scanner, MSYS
changes a command-line argument --libtool="/bin/sh ../../libtool" into
--libtool=c:/opt/msys/1.0/bin/libtool. So just use sh.exe without path
because we already "know" where the libtool configure produced is."
.. yet the actual code was changed to:
_gir_libtool = $(if $(findstring MINGW,$(shell uname -s)),--libtool="$(top_builddir)/libtool",$(if $(LIBTOOL),--libtool="$(LIBTOOL)"))
.. so in fact, if $(uname -s) contained "MINGW", then --libtool ignored
the LIBTOOL variable from automake and used $(top_builddir)/libtool
instead, at the very least, removing all trace of $(SHELL) from it.
Now that $(SHELL) has been re-introduced into libtool, it must not
doubly appear in resolve_windows_libs in ccompiler.py, as otherwise
sh.exe will try to execute sh.exe and that clearly will not work.
I've left some MSYS-specific hacks in dumper.py, some of which could
probaly be removed safely now (execution through a temporary shell
script), but I've opted to leave it as is for now.
This reverts commit 33bbdce144d275b693752f0bc2c2f292deda854e.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently g-ir-scanner fails on macOS when invoked in --no-libtool mode
if the library it links to has not been installed into its destination
(which is likely to be the case). In libtool mode this issue does not
occur as DYLD_LIBRARY_PATH will get set by libtool in an appropriate
manner. This patch ensures DYLD_LIBRARY_PATH will get set.
This patch is also essential for meson and cmake to generate
gobject-introspection bindings.
More information can be found e.g. at
https://mail.gnome.org/archives/gtk-osx-users-list/2018-February/msg00000.html,
and the github repo that was produced subsequently at
https://github.com/wagavulin/gir-mac-sample.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When executing the scanner binary use the PATH/LIB env vars
also under MinGW, since LD_LIBRARY_PATH/rpath doesn't work there.
When resolving the library name from the import library look into
the user provided library paths first before falling back to the
default gcc search path.
This fixes the gir/typelib generation for meson under MSYS2.
Note that MSYS2 ships various patches, so this might not fix it
for all MinGW users.
https://bugzilla.gnome.org/show_bug.cgi?id=791902
|
| |
|
|
|
|
|
|
|
| |
Darwin's linker doesn't like "-rpath=path"; instead pass "-rpath path",
which works on more linkers than the version with the = sign does.
Regressed in commit 5d4cd25292b8ed2c7a821ebe19fc5ab5d447db1a.
https://bugzilla.gnome.org/show_bug.cgi?id=781525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
...the dumper program for all cases. It turned out that using distutils
for linking is more troublesome than useful as we need to ensure that
the paths specified by -L need to come before the standard library search
paths, and distutil's ccompiler.add_library_path() and
ccompiler.add_runtime_library_path() does not work for all of its
supported compilers (Visual Studio is an example).
Instead, we go back to constructing our linker command line manually as
we did before (and as we now do in the libtool case), but with some
enhancements:
-Use '-libpath:' on Visual Studio builds, which corresponds to the -L flag
on GCC/CLang.
-Extend LIB/PATH (Windows/Visual Studio) or LD_LIBRARY_PATH (other
compilers/envs), which is necessary as we resolve the libraries that
are passed into g-ir-scanner, at least on Windows.
-Don't attempt to link to or resolve m.lib on Visual Studio builds, as
the math functions are in the standard CRT .lib/.dll, and there is no
such thing as m.lib
https://bugzilla.gnome.org/show_bug.cgi?id=781525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
For preprocessing, when we create the temp file for preprocessing, make
the temp file be stored in CWD instead of the system's temp directory;
and when we compile the dumper program, set the output_dir to be the
root directory (<drive letter>:\ on Windows and / otherwise).
This is because distutils insists on using the full path from the root
directory to compile sources, so that if we set the output_dir as we now
do we will get
$(abs_srcdir)/$(tmpdir)/<$(abs_srcdir)_minus_rootdir>/$(tmpdir)/<target_gir_file_name>.[o|obj].
https://bugzilla.gnome.org/show_bug.cgi?id=781525
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
str.split() does not handle quoting, so if you have spaces in your
CFLAGS, it will be split incorrectly. For instance:
CFLAGS="'-I/opt/some dir' -DFOO=bar"
>>> os.environ['CFLAGS'].split()
["'-I/opt/some", "dir'", '-DFOO=bar']
>>> shlex.split(os.environ['CFLAGS'])
['-I/opt/some dir', '-DFOO=bar']
https://bugzilla.gnome.org/show_bug.cgi?id=778971
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently the only way to get a library to link against the dumper
program is through '--link' which implies that library will be defined
in the 'libraries' field of the .gir. When using libtool, we
link against dependencies of that library as the .la defines that, but
when using --no-libtool that won't happen and the user needs to be
able to define to what other libraries the program needs to be link
against, and this is what the new --extra-library argument is about.
https://bugzilla.gnome.org/show_bug.cgi?id=774625
|
| |
|
|
|
| |
When resolving libraries, open the temp file generated by dumpbin
with 'r' mode rather than 'rb', since this is a text file.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When using the NMake Makefile within the Visual Studio projects, as we are
using dumpbin to resolve the .lib file that we link to, the outputs of
dumpbin is captured by the Visual Studio output panel, which causes it not
to be processed by proc.communicate(). This is due to dumpbin being an
integrated component of Visual Studio. In order to remedy this, we need to
use a temp file, and use the /out:<tempfile> flag, and look for the DLL
that is linked to by the .lib that we pass in.
https://bugzilla.gnome.org/show_bug.cgi?id=763739
|
| |
|
|
|
|
|
| |
resolve_windows_libs() uses `gcc -print-search-dirs`. When we are cross
compiling with MinGW on linux, gcc uses ':' as path separator, not ';'.
https://bugzilla.gnome.org/show_bug.cgi?id=761981
|
| |
|
|
|
|
|
|
| |
Allow to override it with the DLLTOOL environment variable, leaving
"dlltool" as a fallback when not defined so backward compatibility is
ensured.
https://bugzilla.gnome.org/show_bug.cgi?id=761984
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Avoid crashes due to double shell in subprocess.Popen() on linux, e.g.:
```
>>> import subprocess
>>> subprocess.Popen(['/bin/sh', '/bin/sh'])
/bin/sh: /bin/sh: cannot execute binary file
```
https://bugzilla.gnome.org/show_bug.cgi?id=761982
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 0ff7ca94a608663649defc72021062de098853a8.
As reported by Ting-Wei Lan, this breaks builds with Clang, which
doesn’t support -Wno-cpp.
https://bugzilla.gnome.org/show_bug.cgi?id=757934#c5
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using distutils.ccompiler means that we are forced to use the CFLAGS
from the system’s Python installation, which may contain
-D_FORTIFY_SOURCE. The user’s environment-provided CFLAGS may contain
-O0 (because they are a developer). These two flags cause a warning when
used together. Silence that warning by passing -Wno-cpp to disable
warnings from #warning preprocessor statements in the generated C code.
It doesn’t seem to be possible to selectively undefine _FORTIFY_SOURCE
or to stop using the compiler flags from distutils.sysconfig,
unfortunately.
https://bugzilla.gnome.org/show_bug.cgi?id=757934
|
| |
|
|
|
|
|
|
|
|
| |
Windows builds check the library that was passed into the introspection
scanner to deduce the correct DLL that is to be used by the .gir/.typelib
file, but this was not updated for Python 2.x/3.x compatibility, as the
outputs of a subprocess must be decoded. Fix this for both MSVC and
MinGW-based builds.
https://bugzilla.gnome.org/show_bug.cgi?id=757126
|
| |
|
|
|
|
|
|
|
| |
Darwin's linker doesn't like "-rpath=path"; instead pass "-rpath path",
which works on more linkers than the version with the = sign does.
Additionally, Darwin's linker has no equivalent for "--no-as-needed" (it
seems to do the right thing by default?)
https://bugzilla.gnome.org/show_bug.cgi?id=625195
|
| |
|
|
|
|
|
| |
This allows building in both Python 2 and 3 by fixing a few
text/binary ambiguities and using "as" in an except clause.
https://bugzilla.gnome.org/show_bug.cgi?id=756763
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add unicode_literals future import which turns any string literal
into a unicode string. Return unicode strings from the Python C extension
module. Force writing of annotations (g-ir-annotation-tool) to output utf8
encoded data to stdout.
This is an initial pass at following the "unicode sandwich"
model of programming (http://nedbatchelder.com/text/unipain.html)
needed for supporting Python 3.
https://bugzilla.gnome.org/show_bug.cgi?id=679438
|
| |
|
|
|
|
|
|
| |
Some packages such as GEGL set macro defines directly into CFLAGS,
and distutils don't handle those with quotes well, so we need to deal
with them seperately.
https://bugzilla.gnome.org/show_bug.cgi?id=753428
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add compile() and link() functions in ccompiler.py to call
distutils.ccompiler's compiler() and link() functions, so that we
can in turn call them from dumper.py as needed. Note that for
linking the dumper program when building with libtool, we are still
using the original method of constructing the link command line
and running that command line, as distutils and libtool do not get
along well with each other. For non-libtool builds, such as MSVC
builds, we would link the dumper program using distutils.
For MSVC builds, we need to ignore mt.exe failing to find a
.exe.manifest file as Visual Studio 2010+ do not generate such files
during linking, and it is done by distutils as Python 2.7.x is built
with Visual Studio 2008, which do generate such manifest files during
the build.
https://bugzilla.gnome.org/show_bug.cgi?id=753428
|
| |
|
|
|
|
|
|
| |
This should allow `CC='ccache gcc'` or the like to work.
https://bugzilla.gnome.org/show_bug.cgi?id=753949
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
|
| |
|
|
|
|
|
|
|
| |
This reverts commit 7ce646db1cb0842db2089df671b17081f82f2b0a.
Apparently this patch caused introspection build breakage for gnome-shell,
as problems occurred during linking for libgnome-volume-control.
Please see bug 728313 comment 105 for more details.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add compiler() and link() functions in ccompiler.py to call
distutil.ccompiler's compile() and link() functions, so that we can in turn
call them from dumper.py to build the dumper program. As distutils don't
get along well with libtool libraries (ie .la files), we can deduce the
libraries to link from using the file name .la file and include
$(builddir)/.libs in the linking stage.
For MSVC builds, we need to ignore mt.exe failing to find a .exe.manifest
file as Visual Studio 2010+ do not generate such files during linking, and
it is done by distutils as Python 2.7.x is built with Visual Studio 2008,
which do generate such manifest files during the build.
https://bugzilla.gnome.org/show_bug.cgi?id=728313
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a preprocess() function in ccompiler.py so that it will call the
preprocess() method of the distutils.ccompiler class, and make use of it
from sourcescanner.py.
As we would need to set up the options (include paths, macros, undefs) to
pass into the preprocessor (and later for the compiler), we have a new
private function that translates what we have from the rest of giscanner so
that it could be passed to distutils.ccompiler in a way that it
understands.
Also, as the MSVCCompiler classes in distutils do not provide a
preprocess() implementation, we provide our own so that we can use it when
preprocessing, via distutils, through subclassing MSVCCompiler.
https://bugzilla.gnome.org/show_bug.cgi?id=728313
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This updates the __init__ constructor method of CCompiler so that distutils
can be used, with some environment or user-supplied options to create the
compiler instance that is appropriate with the platform that the giscanner
scripts are being run on, and sets some specific environment for the
compilers as necessary. This also adds a check_is_msvc() method that will
progressively replace calls in the other giscanner scripts that attempt to
check for CC=cl (or so), where a part of which is done in this patch. This
is done for dumper.py as well as it needs to be updated in this patch to
use the updated ccompiler.py which uses distutils to initiate the compiler
instance.
Also, as we have been using the --library option on Windows to pass in the
library (not DLL) to deduce the correct DLL to link to in the introspection
files for some time, we no longer need to make a copy of the library (.lib)
to introspect that matches the <namespace>-<namespace_version>.lib
convention, but use the libraries that were passed in with --library
directly, so that we can link the dumper program during the introspection
build.
Please note that this also partially reverts commit c9cfa2b as the
distutils items are clearly needed for these to work.
https://bugzilla.gnome.org/show_bug.cgi?id=728313
|
| | |
|
| | |
|
|
|
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
|
