qmake for both Qt4 and Qt5 detection was assuming that it was only used
on Windows, which is incorrect. It can also be used on Linux for
cross-compilation or in general when pkg-config is not available.
It was also not failing properly for both Qt5 and Qt4 when no libraries
were found, and was assuming that the .dll was always available.
Qt4 detection with qmake was also completely broken.
Also prevents unwanted injection of partially-found qt dependencies in
targets by unsetting self.cargs and self.largs
MesonDep1 doesn't use symbols from MesonDep2, but uses the MesonDep2
structure definition (so it only needs the header). This means only
generate_gir needs a dependency on MesonDep2 and shared_library doesn't.
This was broken earlier.
MesonSample uses symbols from MesonDep1 and MesonDep2, so both the
library and the gir get a dependency on MesonDep1, and on MesonDep2
(transitively). The transitive dependency was broken earlier.
Earlier, we were never adding dependencies on other GirTargets that we
need. The dependency would only be added indirectly through other
BuildTargets such as SharedLibrary. Now we add all GirTargets specified
in the `dependencies :` kwarg to the list of dependencies of the
GirTarget that we generate.
Also, we weren't adding include directories for the typelib generation
command recursively. We were only adding it for the GirTargets listed
under the `dependencies :` kwarg to gnome.generate_gir. Now we search
all link targets, find GirTargets, extract the include dir, and use it.
In summation, dependencies were completely broken.
Move CCompiler.compile to Compiler.compile so that ValaCompiler can use
it. Also rewrite ValaCompiler.sanity_check to use it since it does
a simple compile check.
At the same time, it enhances ExternalLibrary to support arguments for
languages other than C-like.
Includes a test for this that links against zlib through Vala.
Closes#983
installation.
During a `python3.4 setup.py install`, the yelphelper.py script errors
out with: "SyntaxError: can use starred expression only as assignment
target". Fix this problem.
Instead of using a whitelist, use a blacklist. Also print a more useful
error if the regex fails to match.
Use an underscore in the gir test to trigger this.
Fixes#436
Since Vala require 'glib-2.0' and 'gobject-2.0' dependencies, it's
better to fail at 'valac' step with meaningful error.
Add missing 'gobject-2.0' dependency on the mixed source test case.
The method takes a dictionary with defines names as keys and the defines
values as values. From it, we assemble the gcc version, using 0 as a
default value if the define we want is not defined.
This can only be done as a unit test because it requires changes to the
environment. This also means we need to pass the current environment to
subprocess.check_output, which we should always do anyway since the
environment is torn down and restored between each test.
Instead of blindly searching in PATH, use
Qt5Dependency.compilers_detect() (same for qt4) to get moc/uic/rcc.
This is much more robust, and it improves the chances that the correct
ones will be found. We still manually verify for now because the
fallback in dependencies.py for searching is stll to look in PATH for
backwards-compat, and because people probably have setups like that.
Also sync the qt4 module with the qt5 module w.r.t. resource compilation
and make the compiled qrc.cpp file unique in terms of the framework
version used (4 vs 5). This is needed for the test to work properly,
which now covers both Qt4 and 5.
* Simpler picking of pkg-config vs qmake detection
* qmake-based detection now allows specifying qmake via cross-info
* bindir is now stored from qmake/pkg-config detection and can be used
to detect qt tools such as moc, uic, rcc with self.compilers_detect()
* Qt4 dependencies got some love; now they share the implementation with
Qt5 since the two are very similar; basically identical
* Don't ask about Qt3
Without this a strange exception is spewed that no one would be able to
understand. Finding each of those compilers isn't a problem unless
sources are specified that require those compilers, so only error out in
those cases.
Closes#758
Can only test this by checking the compiler id, but that's good enough.
Disabling so we can get #995 in which will help keep the VS backend in
a better state w.r.t. other PRs.
I've opened #1004 to track this in the meantime.
It causes the cpython tests to fail when using the x86_64 toolchain.
tachyon_module.c.obj : error LNK2019: unresolved external symbol __imp_PyLong_FromLong referenced in function phaserize
tachyon_module.c.obj : error LNK2019: unresolved external symbol __imp_PyArg_ParseTuple referenced in function phaserize
tachyon_module.c.obj : error LNK2019: unresolved external symbol __imp_PyModule_Create2 referenced in function PyInit_tachyon
c:\\python34/libs\python34.lib : warning LNK4272: library machine type 'X86' conflicts with target machine type 'x64'
ext/tachyon.pyd : fatal error LNK1120: 3 unresolved externals
This is useful to know what MSBuild.exe and Ninja we are using and
whether the correct one has been set via PATH by vcvarsall.bat and
hasn't been overwritten by appveyor.
With MSVC 2013 and newer, using pre-compiled headers with .pdb debugging
fails with the following error message:
fatal error C1041: cannot open program database '[...]\prog.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
So we use /FS when PCH is enabled. When PCH is enabled and debugging is
disabled, this will have no effect since .pdb files will not be written.
The code generated manually with manygen.py must use the same CRT
compiler arguments as the final executable itself or we get an error
during linking:
MSVCRTD.lib(_chandler4gs_.obj) : error LNK2019: unresolved external symbol __except_handler4_common referenced in function __except_handler4
depuser.exe : fatal error LNK1120: 1 unresolved externals
The pkg-config version shipped with MinGW is too old, and the test is
sufficiently covered on Linux, so just skip it on Windows. We anyway do
not run the other pkg-config tests on Windows.
Previously we were just dumping all defines and include directories into
the target-wide list of defines and include directories. Now we have
separate per-target and per-file (actually per-language) arguments,
defines, and include directories.
There is no way to do this in the .appveyor.yml file since it seems that
the appveyor environment is forcibly written after each cmd command that
is run.
Now we test:
MSVC 2010 + Ninja (x86)
MSVC 2015 + Ninja (x86)
MSVC 2015 + Ninja (x86_64)
MSVC 2010 + MSBuild (x86)
MSVC 2015 + MSBuild (x86)
MSVC 2015 + MSBuild (x86_64)
MSVC 2010 Express only shipped with an x86 toolchain, so we can only
test x86 for that.
- Use depfile support on recent glib-compile-resources
- Don't pass dep files to header ever
- Pass depends for generated deps
- Avoid duplicate --sourcedir args
- Include correct subdir of generated deps
Nirbheek Chauhan
Guillaume Poirier-Morency
Jussi Pakkanen
Thibault Saunier
Olexa Bilaniuk
Scott D Phillips
Paulo Antonio Alvarez
Patrick Griffis