aboutsummaryrefslogtreecommitdiff
path: root/test cases
AgeCommit message (Collapse)AuthorFilesLines
2019-06-20add inline comment test for Fortran submoduleMichael Hirsch, Ph.D1-1/+1
2019-06-20add inline comment test for Fortran includeMichael Hirsch, Ph.D1-1/+1
2019-06-20BUGFIX syntaxMichael Hirsch, Ph.D1-2/+2
2019-06-19make test more stringent by building separate libraryMichael Hirsch, Ph.D1-1/+4
2019-06-19add fortran module inline comment testMichael Hirsch, Ph.D5-10/+21
2019-06-19Skip `196 install_mode` project test on WindowsAleksey Gurtovoy1-0/+4
2019-06-12cmake: Fix missing include_directories in some CMakeLists.txtDaniel Mensinger3-2/+4
2019-06-12modules/python: add a modules keyword argumentDylan Baker1-0/+7
This mirrors the modules keyword argument that some dependencies (such as qt and llvm) take. This allows an easier method to determine if modules are installed.
2019-06-09Make test for identityJohn Ericson4-0/+52
(cherry picked from commit ae6426cd8acfe0ccc5d7958d55edb613b4a5bf01)
2019-06-09Purge `is_cross` and friends without changing user interfacesJohn Ericson1-6/+1
In most cases instead pass `for_machine`, the name of the relevant machines (what compilers target, what targets run on, etc). This allows us to use the cross code path in the native case, deduplicating the code. As one can see, environment got bigger as more information is kept structured there, while ninjabackend got a smaller. Overall a few amount of lines were added, but the hope is what's added is a lot simpler than what's removed.
2019-06-06cmake: Updated test casesDaniel Mensinger7-27/+34
2019-06-06cmake: fixed installed_files.txtDaniel Mensinger2-2/+10
2019-06-06cmake: Fixed test cases for windowsDaniel Mensinger34-12/+177
2019-06-06cmake: Added option for additional CMake argsDaniel Mensinger2-0/+8
2019-06-06cmake: support object librariesDaniel Mensinger7-0/+54
2019-06-06cmake: Added test for configure_fileDaniel Mensinger4-0/+16
2019-06-06cmake: Added Code generation testDaniel Mensinger5-0/+57
2019-06-06cmake: Added project testsDaniel Mensinger5-6/+22
2019-06-06cmake: extract the codemodelDaniel Mensinger6-0/+65
2019-06-06cmake: Server handshakeDaniel Mensinger5-0/+45
2019-06-05Add tests for std usage. Closes #5097.Jussi Pakkanen2-0/+3
(cherry picked from commit 27ae70dfaaff1298e68df70098acaa96f7ca748a)
2019-06-05Per machine do 'build.' and '' option prefixesJohn Ericson3-1/+17
See the docs/ changes for details.
2019-06-05Merge pull request #5436 from dcbaker/cmake-lexer-spaces-in-argsJussi Pakkanen2-0/+82
Cmake lexer spaces in args
2019-06-05rewriter: Fix that default_options would not set the correct idDaniel Mensinger1-1/+1
Currently default_options uses "" for the kwarks id, however this is incorect and it must be "/". Additionally, this error won't be ignored in the future with "--skip" (this is why the tests were passing and this wasn't detected earlier).
2019-05-29dependencies/cmake: correctly handle spaces in variable namesDylan Baker1-4/+4
2019-05-29tests: Test the cmake parser more thuroughlyDylan Baker2-0/+82
It turns out there are bugs, in particular with spaces in variables...
2019-05-28interpreter: add fallback argument to subproject.get_variable()Mathieu Duponchelle1-0/+5
2019-05-28gnome: make sure the target build directory is passed first for linkingChristoph Reiter4-0/+99
determine_rpath_dirs() can return paths to external dependencies not in the build dir and passing them first as a link path leads to g-ir-scanner for example linking against the already installed library instead of the just built one. This was reported in g-i: https://gitlab.gnome.org/GNOME/gobject-introspection/issues/272 and comes up quite often when a library adds some new symbols which aren't present in the system library, which then makes linking fail. The first place where the order is changed is _scan_gir_targets(), which looks like an unintentional change in the refactoring in 8377ea45aa61efbe8e1a75b74 The second place in _get_link_args() has always been that way and only the rpath order is changed, but it looks to me as if the same rules should apply here too.
2019-05-27coredata: add cmake_prefix_path optionDylan Baker2-0/+8
2019-05-22sourceset: add a realistic example as a testcasePaolo Bonzini23-0/+327
2019-05-22new module "sourceset" to match source file lists against configuration dataPaolo Bonzini22-0/+248
In QEMU a single set of source files is built against many different configurations in order to generate many executable. Each executable includes a different but overlapping subset of the source files; some of the files are compiled separately for each output, others are compiled just once. Using Makefiles, this is achieved with a complicated mechanism involving a combination of non-recursive and recursive make; Meson can do better, but because there are hundreds of such conditional rules, it's important to keep meson.build files brief and easy to follow. Therefore, this commit adds a new module to satisfy this use case while preserving Meson's declarative nature. Configurations are mapped to a configuration_data object, and a new "source set" object is used to store all the rules, and then retrieve the desired set of sources together with their dependencies. The test case shows how extract_objects can be used to satisfy both cases, i.e. when the object files are shared across targets and when they have to be separate. In the real-world case, a project would use two source set objects for the two cases and then do "executable(..., sources: ... , objects: ...)". The next commit adds such an example.
2019-05-21Merge pull request #5372 from dcbaker/get_variableJussi Pakkanen1-0/+52
Dependency.get_variable method
2019-05-20Generators can have extra target dependencies. Closes #4131.Jussi Pakkanen6-0/+50
2019-05-20Combine the two different pipeline test dirs into one.Jussi Pakkanen6-5/+4
2019-05-20fixup! fixup! tests: Add test for Dependency.get_variableDylan Baker1-7/+7
2019-05-16compilers/fortran: Fix all has_argument methods in mesonDylan Baker1-1/+4
Apparently we have no tests for this because this is broken pretty badly. This extends the basic test to actually check for the correct free-form argument and thus test this.
2019-05-14Merge pull request #5331 from dcbaker/iclJussi Pakkanen13-20/+25
ICL (Intel for Windows) support
2019-05-13ast: fix #5376Daniel Mensinger1-0/+7
2019-05-10tests/fortran/14: Add vsdef filesDylan Baker2-1/+3
ICL and ifort need these to pass this tests.
2019-05-10tests/fortran/9 cpp: It's okay to link ICL and ifortDylan Baker1-1/+1
This test currently assumes that the fortran compiler is gfotran, and if we're not using g++ it skips. This patch changes it to skip if the fotran compiler and the c++ compiler aren't the same family. This still may skip in some cases it shouldn't (clang and gfort probably work fine on windows), but it does enable ifort + ICL. Which is hte point.
2019-05-10tests/fortran/1: call compiler.get_id() == str instead of compiler == strDylan Baker1-1/+1
2019-05-10tests/204: Fix intel-cl expectationsDylan Baker1-2/+2
2019-05-10tests/206: Fix intel vs intel-cl expectationsDylan Baker1-8/+2
2019-05-10tests/143: Add xilib check for ICLDylan Baker1-0/+2
2019-05-10tests/132: ICL should not run this test like MSVC and clang-clDylan Baker1-1/+1
2019-05-10tests/124: ICL alos does not use ASMDylan Baker1-1/+1
2019-05-10tests/123: Add /nologo to cl and mlDylan Baker1-2/+2
To make them less chatty.
2019-05-10tests/123: For MSVC like compilers to treat the .S file like a .c fileDylan Baker1-1/+2
Which is required for ICL to work correctly, as it otherwise assumes that the .S file is a .o/.obj file.
2019-05-10tests/common/40: ICL behaves like MSVC and should be tested like itDylan Baker1-1/+1
2019-05-10test cases: Add ICL branches in addition to ICC branchesDylan Baker2-2/+8
generated by cgit v1.1 at 2025-09-23 20:57:55 +0000