aboutsummaryrefslogtreecommitdiff
path: root/mesonbuild/modules/windows.py
AgeCommit message (Collapse)AuthorFilesLines
2023-12-13Use SPDX-License-Identifier consistentlyDylan Baker1-11/+1
This replaces all of the Apache blurbs at the start of each file with an `# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing uses to be consistent in capitalization, and to be placed above any copyright notices. This removes nearly 3000 lines of boilerplate from the project (only python files), which no developer cares to look at. SPDX is in common use, particularly in the Linux kernel, and is the recommended format for Meson's own `project(license: )` field
2023-08-18Add more descriptive description to CustomTargetCharles Brunet1-0/+1
Allow modules using CustomTarget to modify the command description used by ninja backend. This result in more precise logs when building a project.
2023-07-10windows: Fix detection of the llvm-rc resource compilerMartin Storsjö1-0/+1
By default, clang-cl based environments use rc.exe as resource compiler. However, when cross compiling with clang-cl, one might want to use llvm-rc instead. Try to detect llvm-rc based on the output from "$CMD /?". This requires a very recent llvm-rc; previosly, the output of "/?" with llvm-rc was very generic and didn't explicitly indicate that it actually was llvm-rc. This was changed in https://github.com/llvm/llvm-project/commit/bab6902eba55026a829d232629f99ac276936ef0 which will be included in the upcoming LLVM 17.0.0 release. Contrary to the other regexes, don't include the preceding parts of the line in the log printout, as it includes an unhelpful "OVERVIEW:" prefix.
2023-06-15windows: Fix windres detection for Microsoft shipped ClangL. E. Segovia1-1/+2
Clang, clang-cl, and MSVC all rely on RC.EXE to build resource files. Fixes #11845
2023-04-11fix various spelling issuesJosh Soref1-1/+1
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
2023-02-01treewide: add future annotations importEli Schwartz1-0/+1
2022-08-31Fix 2 typos in a single string which can be shown in error messages.Jehan1-1/+1
2022-08-17modules: use module level information about new and deprecationDylan Baker1-1/+4
Instead of using FeatureNew/FeatureDeprecated in the module. The goal here is to be able to handle information about modules in a single place, instead of having to handle it separately. Each module simply defines some metadata, and then the interpreter handles the rest.
2022-06-17fix confusing incorrect default name for a KwargInfoEli Schwartz1-1/+1
We can use this lots of places, and it's always the same kwarg. There doesn't seem to be a point in naming it badly, then evolving it to the standard name in the one place it is currently used. This made it not shareable.
2022-03-29Pass environment down to base Target classXavier Claessens1-0/+1
2022-01-28build: replace kwargs in CustomTarget initializerDylan Baker1-14/+13
Because we don't want to pass the Interpreter kwargs into the build layer. This turned out to be a mega commit, as there's really on elegant way to make this change in an incremental way. On the nice side, mypy made this change super easy, as nearly all of the calls to `CustomTarget` are fully type checked! It also turns out that we're not handling install_tags in custom_target correctly, since we're not converting the boolean values into Optional values!
2021-12-17Fix mypy errorsDaniel Mensinger1-1/+11
2021-11-20add location nodes to some Feature callsEli Schwartz1-2/+4
2021-10-09modules/windows: allow CustomTargets with more than one output for ↵Dylan Baker1-17/+20
compile_resources
2021-10-09modules/windows: allow CustomTargetIndex for compile_resourcesDylan Baker1-3/+5
In the positional arguments
2021-10-09modules/windows: use typed_kwargsDylan Baker1-21/+38
2021-10-08modules/windows: use typed_pos_argsDylan Baker1-11/+7
2021-10-08modules/windows: add some easy type annotationsDylan Baker1-11/+18
This isn't complete, it's just the easy stuff
2021-10-07Windows module: Make path flattening for windres work in more casesLuca Bacci1-2/+2
If either 'name' or 'name_formatted' are absolute paths, then they are of the form: C:\path/to/file.ext (example) By only substituting slashes with the underscore, we get: C:_path_to_file.ext This is still not quite right, infact os.path.basename() returns: _path_to_file.ext Also replace colons with underscores to overcome issues when absolute paths are involved.
2021-07-07windows: Support wrc resource compilerConnor Abbott1-1/+6
It has a similar interface to windres, but it produces ELF instead of COFF binaries. It uses its own preprocessor which doesn't support creating depfiles, but we can convince it to use the system preprocessor instead and pass those arguments using the --preprocessor option. Together with some hacks to override the shared library/executable suffix and some wine patches [1] this is enough to compile dxvk when ripping out the hand-rolled rc support. [1] https://www.winehq.org/pipermail/wine-devel/2021-July/190100.html https://www.winehq.org/pipermail/wine-devel/2021-July/190098.html https://www.winehq.org/pipermail/wine-devel/2021-July/190099.html https://www.winehq.org/pipermail/wine-devel/2021-July/190101.html
2021-06-18holders: remove unholderDaniel Mensinger1-6/+6
2021-05-28modules: Add methods dict everywhereXavier Claessens1-0/+5
This fix calling random internal methods from meson.build as long as they were not prefixed by underscore.
2021-05-12gnome: Fix gtkdoc generationXavier Claessens1-3/+2
install_scripts used to replace @BUILD_ROOT@ and @SOURCE_ROOT@ but it was not documented and got removed in Meson 0.58.0. gnome.gtkdoc() was relying on that behaviour, but it has always been broken in the case the source or build directory contains spaces. Fix this by changing get_include_args() to substitue paths directly which will then get escaped correctly. Add a unit test that builds GObject documentation which is where this issue has been spotted. Fixes: #8744
2021-03-19split program related classes and functions out of dependenciesDylan Baker1-1/+1
Dependencies is already a large and complicated package without adding programs to the list. This also allows us to untangle a bit of spaghetti that we have.
2021-03-04mass rewrite of string formatting to use f-strings everywhereEli Schwartz1-1/+1
performed by running "pyupgrade --py36-plus" and committing the results
2020-10-15windows: Avoid target name clash happening in GTK+Xavier Claessens1-1/+3
2020-09-28windows: reduce chance of going over path limit in backend/vsPeter Harris1-4/+5
When building with vs2019 (not ninja), a path length error will be thrown if the path to a resource file is even remotely deep within the tree. This is largely because the target name includes the string "Windows resource for file 'full path'", which is then expanded twice (once for the .vcxproj itself, and once for IntDir) and added to the full path. When combined with the tiny path limits on Windows, it is easy to exceed path limits. This error is largely avoided by the ninja back-end. Unlike the vs back-end, the ninja back-end does not use target.get_id() as part of the project file path, nor does it use target.get_id() as part of get_target_private_dir(). Example error: error MSB4184: The expression "[MSBuild]::NormalizePath( C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp, f3f7317@@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\, f3f7317@@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus. vcxproj.CopyComplete)" cannot be evaluated. Path: C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp\f3f7317 @@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\f3f7317 @@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus. vcxproj.CopyComplete exceeds the OS max path limit. The fully qualified file name must be less than 260 characters.
2020-09-17Revert "windows: reduce chance of going over path limit in backend/vs"Nirbheek Chauhan1-5/+4
This reverts commit 807f88739ebfa002c9a0b9acd3e24c9610fb02a2.
2020-09-17windows: reduce chance of going over path limit in backend/vsPeter Harris1-4/+5
When building with vs2019 (not ninja), a path length error will be thrown if the path to a resource file is even remotely deep within the tree. This is largely because the target name includes the string "Windows resource for file 'full path'", which is then expanded twice (once for the .vcxproj itself, and once for IntDir) and added to the full path. When combined with the tiny path limits on Windows, it is easy to exceed path limits. This error is largely avoided by the ninja back-end. Unlike the vs back-end, the ninja back-end does not use target.get_id() as part of the project file path, nor does it use target.get_id() as part of get_target_private_dir(). Example error: error MSB4184: The expression "[MSBuild]::NormalizePath( C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp, f3f7317@@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\, f3f7317@@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus. vcxproj.CopyComplete)" cannot be evaluated. Path: C:\src\mesonbuild\Misc\FreeRDP-master\client\X11\xfreerdp\xfreerdp\f3f7317 @@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus\f3f7317 @@Windows resource for file 'Misc_FreeRDP-master_client_X11_xfreerdp_xfreerdp_xfreerdp.rc'@cus. vcxproj.CopyComplete exceeds the OS max path limit. The fully qualified file name must be less than 260 characters.
2020-07-05Don't make unactionable warnings fatalNirbheek Chauhan1-1/+1
Some warnings are out of the user's control, such as the RCC QT bug, or the GNU windres bug, or our informational warning about auto-disabling of options when -Db_bitcode is enabled. Such warnings should not be fatal when --fatal-meson-warnings is passed because there's no action that the user can take to fix it. The only purpose it serves is to prevent people who use those features from using --fatal-meson-warnings.
2020-03-23Fix legacy env var support with crossJohn Ericson1-1/+1
Fix #3969
2020-03-05Make use of unholderDylan Baker1-4/+2
We have a lot of cases of code like: ```python if hasattr(var, 'held_object'): var = var.held_object` ``` replace that with the unholder function.
2019-07-05Fix windres module argument flatteningePirat1-2/+2
2019-06-09Purge `is_cross` and friends without changing user interfacesJohn Ericson1-4/+5
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-05-20Remove compilers from ModuleState objectJon Turney1-1/+1
It doesn't make much sense to have this and not also have cross-compilers (so any use of this is already pretty suspect as probably wrong when cross-compiling). This information is accessible anyhow via environment.coredata.
2019-05-13modules/windows: ICL uses rc, not windresDylan Baker1-1/+1
2019-04-29Fix builtin variable namesDaniel Mensinger1-2/+2
2019-01-02Remove cross_info; cross file is parsed up front and discardedJohn Ericson1-19/+3
2018-11-14modules/python3: allow specifying in the native fileDylan Baker1-3/+2
2018-11-14modules/windows: Allow getting windres from native fileDylan Baker1-0/+8
2018-11-14replace ExternalProgram.from_cross_info with from_bin_listDylan Baker1-2/+2
This more generic method will also be used to check a config file for binary information.
2018-11-04Use 'rc' resource compiler with clang-cl toolchainJon Turney1-1/+1
The LLVM toolchain doesn't come with a Windows resource compiler at the moment. Use 'rc' from the Windows SDK.
2018-10-02Probe Windows resource compiler typeJon Turney1-4/+22
Determine the type of the Windows resource compiler by looking at its output, not its name. Also log the name and version of the resource compiler we are using.
2018-10-01Factor out windows resource compiler determinationJon Turney1-17/+25
Factor out determination of the windows resource compiler as _find_resource_compiler(). Cache the result, so the work is only done once.
2018-09-10Improve windows resource compiler executable selectionJon Turney1-21/+35
Always honour any windres setting in cross-file (we can't be compiling with msvc, but this should apply when cross-compiling using gcc or clang) Always honour WINDRES environment variable Otherwise look for the resource compiler which is part of the same toolset as the C or C++ compiler. Add some commentary on why the conventions for compiled resource file extensions differ between RC and windres Also don't try to report non-existent path when we couldn't find the resource compiler.
2018-08-27Remove some spurious calls to the format() functionJon Turney1-3/+3
Remove some spurious calls to the format() function, left by mistake after c2f37853
2018-08-16Use unique output for windows.compile_resources()Jon Turney1-12/+15
Use a unique output filename for windows.compile_resources() even when input basename is not unique.
2018-07-01Add a helper for fetching of binaries from cross filesNirbheek Chauhan1-8/+10
A number of cases have to be taken care of while doing this, so refactor it into a helper on ExternalProgram and use it everywhere. 1. Command is a list of len > 1, use it as-is 2. Command is a list of len == 1 (or a string), use as a string 3. If command is an absolute path, use it as-is 4. If command is not an absolute path, search for it
2018-06-18Make depends: of windows.compile_resources() include-ableJon Turney1-0/+4
Add the output directories for any custom target in depends: to the resource compiler include path
2018-06-18Add a depends: keyword to windows.compile_resources()Jon Turney1-4/+6
Expose depends: from the custom_target this creates.
generated by cgit v1.1 at 2024-08-28 03:04:43 +0000