tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/source/blender/windowmanager/CMakeLists.txt

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

222 lines
4.2 KiB
CMake
Raw Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS Listing the "Blender Foundation" as copyright holder implied the Blender Foundation holds copyright to files which may include work from many developers. While keeping copyright on headers makes sense for isolated libraries, Blender's own code may be refactored or moved between files in a way that makes the per file copyright holders less meaningful. Copyright references to the "Blender Foundation" have been replaced with "Blender Authors", with the exception of `./extern/` since these this contains libraries which are more isolated, any changed to license headers there can be handled on a case-by-case basis. Some directories in `./intern/` have also been excluded: - `./intern/cycles/` it's own `AUTHORS` file is planned. - `./intern/opensubdiv/`. An "AUTHORS" file has been added, using the chromium projects authors file as a template. Design task: #110784 Ref !110783.
2023-08-15 16:20:26 +02:00
# SPDX-FileCopyrightText: 2006 Blender Authors
Cleanup: Add a copyright notice to files and use SPDX format A lot of files were missing copyright field in the header and the Blender Foundation contributed to them in a sense of bug fixing and general maintenance. This change makes it explicit that those files are at least partially copyrighted by the Blender Foundation. Note that this does not make it so the Blender Foundation is the only holder of the copyright in those files, and developers who do not have a signed contract with the foundation still hold the copyright as well. Another aspect of this change is using SPDX format for the header. We already used it for the license specification, and now we state it for the copyright as well, following the FAQ: https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
#
File headers: SPDX License migration Use a shorter/simpler license convention, stops the header taking so much space. Follow the SPDX license specification: https://spdx.org/licenses - C/C++/objc/objc++ - Python - Shell Scripts - CMake, GNUmakefile While most of the source tree has been included - `./extern/` was left out. - `./intern/cycles` & `./intern/atomic` are also excluded because they use different header conventions. doc/license/SPDX-license-identifiers.txt has been added to list SPDX all used identifiers. See P2788 for the script that automated these edits. Reviewed By: brecht, mont29, sergey Ref D14069
2022-02-10 23:07:11 +01:00
# SPDX-License-Identifier: GPL-2.0-or-later
Support for CMake
2008-01-03 23:20:45 +01:00
- added back zlib include (needed for win32). - use list append in more places. - remove non existing include dir.
2010-09-07 03:13:10 +02:00
set(INC
CMake: revert last weeks modernizations The cleanup of blenkernel last weeks , caused the house of cards to collapse on top of bf_gpu's shader_builder, which is off by default but used on a daily basis by the rendering team. Given the fixes forward in #110394 ran into a ODR violation in OSL that was hiding there for years, I don't see another way forward without impeding the rendering teams productivity for "quite a while" as there is no guarantee the OSL issue would be the end of it. the only way forward appears to be back. this reverts : 19422044edbd8e8d524db3d02768c4a52f5274be a670b53abe82f7a36d2caa0d8ae2c67c2bc8c39a 0f541db97c47e5fcd1c71160d71642235d9ea743 be516e8c814dbf7bc43ea91c6913be9f7f96e006 3e88a2f44c413fa7f671f638409a975d59f8c1fb 4e64b772f5ed8f352c2744baece802f70e2430e7 9547e7a317d6f86ab8fbfb3d440f127c2ab75df2 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd The problematic commit was 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd as blenkernel links most of blender, it's a bit of a link order issue magnet. Given all these commits stack, it's near impossible to revert just that one without spending a significant amount of time resolving merge conflicts. 99% of that work was automated, so easier to just revert all of them, and re-do the work, than it is to deal with the merge conflicts. Pull Request: https://projects.blender.org/blender/blender/pulls/110438
2023-07-25 16:43:21 +02:00
.
gizmo
gizmo/intern
Asset system: New asset system code module (with files from BKE) Adds a new `source/blender/asset_system` directory and moves asset related files from BKE to it. More asset related code can follow (e.g. asset indexing, ED_assetlist stuff) but needs further work to untangle it. I also kept `BKE_asset.h` and `asset.cc` as is, since they deal with asset DNA data mostly, thus make sense in BKE. Motivation: - Makes the asset system design more present (term wasn't even used in code before). - An `asset_system` directory is quite descriptive (trivial to identify core asset system features) and makes it easy to find asset code. - Asset system is mostly runtime data, with little relation to other `Main`/BKE/DNA types. - There's a lot of stuff in BKE already. It shouldn't be just a dump for all stuff that seems core enough. - Being its own directly helps us be more mindful about encapsulating the module well, and avoiding dependencies on other modules. - We can be more free with splitting files here than in BKE. - In future there might be an asset system BPY module, which would then map quite nicely to the `asset_system` directory. Checked with some other core devs, consensus seems that this makes sense.
2022-11-14 12:41:55 +01:00
../asset_system
CMake: revert last weeks modernizations The cleanup of blenkernel last weeks , caused the house of cards to collapse on top of bf_gpu's shader_builder, which is off by default but used on a daily basis by the rendering team. Given the fixes forward in #110394 ran into a ODR violation in OSL that was hiding there for years, I don't see another way forward without impeding the rendering teams productivity for "quite a while" as there is no guarantee the OSL issue would be the end of it. the only way forward appears to be back. this reverts : 19422044edbd8e8d524db3d02768c4a52f5274be a670b53abe82f7a36d2caa0d8ae2c67c2bc8c39a 0f541db97c47e5fcd1c71160d71642235d9ea743 be516e8c814dbf7bc43ea91c6913be9f7f96e006 3e88a2f44c413fa7f671f638409a975d59f8c1fb 4e64b772f5ed8f352c2744baece802f70e2430e7 9547e7a317d6f86ab8fbfb3d440f127c2ab75df2 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd The problematic commit was 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd as blenkernel links most of blender, it's a bit of a link order issue magnet. Given all these commits stack, it's near impossible to revert just that one without spending a significant amount of time resolving merge conflicts. 99% of that work was automated, so easier to just revert all of them, and re-do the work, than it is to deal with the merge conflicts. Pull Request: https://projects.blender.org/blender/blender/pulls/110438
2023-07-25 16:43:21 +02:00
../blenkernel
- added back zlib include (needed for win32). - use list append in more places. - remove non existing include dir.
2010-09-07 03:13:10 +02:00
../blenloader
CMake: revert last weeks modernizations The cleanup of blenkernel last weeks , caused the house of cards to collapse on top of bf_gpu's shader_builder, which is off by default but used on a daily basis by the rendering team. Given the fixes forward in #110394 ran into a ODR violation in OSL that was hiding there for years, I don't see another way forward without impeding the rendering teams productivity for "quite a while" as there is no guarantee the OSL issue would be the end of it. the only way forward appears to be back. this reverts : 19422044edbd8e8d524db3d02768c4a52f5274be a670b53abe82f7a36d2caa0d8ae2c67c2bc8c39a 0f541db97c47e5fcd1c71160d71642235d9ea743 be516e8c814dbf7bc43ea91c6913be9f7f96e006 3e88a2f44c413fa7f671f638409a975d59f8c1fb 4e64b772f5ed8f352c2744baece802f70e2430e7 9547e7a317d6f86ab8fbfb3d440f127c2ab75df2 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd The problematic commit was 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd as blenkernel links most of blender, it's a bit of a link order issue magnet. Given all these commits stack, it's near impossible to revert just that one without spending a significant amount of time resolving merge conflicts. 99% of that work was automated, so easier to just revert all of them, and re-do the work, than it is to deal with the merge conflicts. Pull Request: https://projects.blender.org/blender/blender/pulls/110438
2023-07-25 16:43:21 +02:00
../blentranslation
code cleanup: - move object_iterators.c --> view3d_iterators. (ED_object.h had to include ED_view3d.h which isn't so nice) - move projection functions from view3d_view.c --> view3d_project.c (view3d_view was becoming a mishmash of utility functions and operators). - some some cmake includes as system-includes.
2012-10-17 06:13:03 +02:00
../compositor
- added back zlib include (needed for win32). - use list append in more places. - remove non existing include dir.
2010-09-07 03:13:10 +02:00
../editors/include
DRW: Add new Draw Manager OpenGL Context. This separate context allows two things: - It allows viewports in multi-windows configuration. - F12 render can use this context in a separate thread and do a non-blocking render. The downside is that the context cannot be used while rendering so a request to refresh a viewport will lock the UI. This is something that will be adressed in the future. Under the hood what does that mean: - Not adding more mess with VAOs management in gawain. - Doing depth only draw for operators / selection needs to be done in an offscreen buffer. - The 3D cursor "autodis" operator is still reading the backbuffer so we need to copy the result to it. - All FBOs needed by the drawmanager must to be created/destroyed with its context active. - We cannot use batches created for UI in the DRW context and vice-versa. There is a clear separation of resources that enables the use of safe multi-threading.
2018-02-26 19:41:17 +01:00
../draw
cmake: cleanup include paths, some duplicates and going up some unneeded dirs.
2011-07-17 11:11:13 +02:00
../gpu
CMake: Fix Compiling Shader Builder on macOS Due to changes in the build environment shader_builder wasn't able to compile on macOs. This patch reverts several recent changes to CMake files. * dbb2844ed98f91395856ac3def258f170d78a819 * 94817f64b9780287be94f9c7a46257709622497d * 1b6cd937ffc8279aadeee2b262690452dea8c7d9 The idea is that in the near future shader_builder will run on the buildbot as part of any regular build to ensure that changes to the CMake doesn't break shader_builder and we only detect it after a few days. Pull Request: https://projects.blender.org/blender/blender/pulls/115929
2023-12-08 15:47:14 +01:00
../imbuf
cmake: cleanup include paths, some duplicates and going up some unneeded dirs.
2011-07-17 11:11:13 +02:00
../makesrna
../nodes
Cleanup: Render Module: move header files to main directory Move headers files from `render/extern/` to `render/` Part of T73586
2020-11-06 16:10:18 +01:00
../render
Move sequencer sources from blenkernel This is first step of refactoring task T77580. Next step will be breaking up files into smaller ones. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D8492
2020-10-05 02:58:56 +02:00
../sequencer
cmake: cleanup include paths, some duplicates and going up some unneeded dirs.
2011-07-17 11:11:13 +02:00
../../../intern/memutil
CMake: revert last weeks modernizations The cleanup of blenkernel last weeks , caused the house of cards to collapse on top of bf_gpu's shader_builder, which is off by default but used on a daily basis by the rendering team. Given the fixes forward in #110394 ran into a ODR violation in OSL that was hiding there for years, I don't see another way forward without impeding the rendering teams productivity for "quite a while" as there is no guarantee the OSL issue would be the end of it. the only way forward appears to be back. this reverts : 19422044edbd8e8d524db3d02768c4a52f5274be a670b53abe82f7a36d2caa0d8ae2c67c2bc8c39a 0f541db97c47e5fcd1c71160d71642235d9ea743 be516e8c814dbf7bc43ea91c6913be9f7f96e006 3e88a2f44c413fa7f671f638409a975d59f8c1fb 4e64b772f5ed8f352c2744baece802f70e2430e7 9547e7a317d6f86ab8fbfb3d440f127c2ab75df2 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd The problematic commit was 07fe6c5a57d7bcf89318204c0319db1f4a2f5cbd as blenkernel links most of blender, it's a bit of a link order issue magnet. Given all these commits stack, it's near impossible to revert just that one without spending a significant amount of time resolving merge conflicts. 99% of that work was automated, so easier to just revert all of them, and re-do the work, than it is to deal with the merge conflicts. Pull Request: https://projects.blender.org/blender/blender/pulls/110438
2023-07-25 16:43:21 +02:00
../bmesh
Refactor: move wmWindowManager .blend I/O to IDTypeInfo callbacks
2020-11-06 13:04:44 +01:00
RNA: Generate property declerations header, solving msg-bus C++ incompatibility Lets `makesrna` generate a `RNA_prototypes.h` header with declarations for all RNA properties. This can be included in regular source files when needing to reference RNA properties statically. This solves an issue on MSVC with adding such declarations in functions, like we used to do. See 800fc1736748. Removes any such declarations and the related FIXME comments. Reviewed By: campbellbarton, LazyDodo, brecht Differential Revision: https://developer.blender.org/D13837
2022-03-14 16:39:42 +01:00
# RNA_prototypes.h
${CMAKE_BINARY_DIR}/source/blender/makesrna
cmake maintenance blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python). also only build wm_apple.c on apple+carbon configuration.
2011-05-31 03:15:44 +02:00
)
Cleanup: quiet uninitialized warnings
2023-07-29 05:47:57 +02:00
set(INC_SYS
)
cmake maintenance blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python). also only build wm_apple.c on apple+carbon configuration.
2011-05-31 03:15:44 +02:00
use explicit file paths for CMake rather then globing, This is recommended by cmake devs. globbing vs explicit is discussed here. http://www.cmake.org/pipermail/cmake/2008-December/025694.html Practical implications are: - developers need to keep CMakeLists.txt files up to date. - Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
2010-10-23 06:05:55 +02:00
set(SRC
WM: move to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110292
2023-07-20 22:12:29 +02:00
intern/wm.cc
intern/wm_cursors.cc
Cleanup: Move wm_dragdrop.c to C++
2022-07-27 06:12:06 +02:00
intern/wm_dragdrop.cc
WM: move to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110292
2023-07-20 22:12:29 +02:00
intern/wm_draw.cc
intern/wm_event_query.cc
Cleanup: Move wm_event_system.c to C++ This allows the use of C++ data structures to simplify code and improve performance.
2022-06-05 16:47:42 +02:00
intern/wm_event_system.cc
Cleanup: move some undo related files to C++ For continued testing in D14139. Also see T103343.
2023-01-23 00:32:39 +01:00
intern/wm_files.cc
WM: move to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110292
2023-07-20 22:12:29 +02:00
intern/wm_files_link.cc
intern/wm_gesture.cc
intern/wm_gesture_ops.cc
Cleanup: move some undo related files to C++ For continued testing in D14139. Also see T103343.
2023-01-23 00:32:39 +01:00
intern/wm_init_exit.cc
WM: move to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110292
2023-07-20 22:12:29 +02:00
intern/wm_jobs.cc
intern/wm_keymap.cc
intern/wm_keymap_utils.cc
intern/wm_menu_type.cc
intern/wm_operator_props.cc
intern/wm_operator_type.cc
intern/wm_operator_utils.cc
intern/wm_operators.cc
intern/wm_panel_type.cc
intern/wm_platform_support.cc
intern/wm_playanim.cc
intern/wm_splash_screen.cc
intern/wm_stereo.cc
intern/wm_subwindow.cc
intern/wm_surface.cc
intern/wm_toolsystem.cc
intern/wm_tooltip.cc
intern/wm_uilist_type.cc
intern/wm_utils.cc
intern/wm_window.cc
gizmo/intern/wm_gizmo.cc
gizmo/intern/wm_gizmo_group.cc
gizmo/intern/wm_gizmo_group_type.cc
gizmo/intern/wm_gizmo_map.cc
gizmo/intern/wm_gizmo_target_props.cc
gizmo/intern/wm_gizmo_type.cc
message_bus/intern/wm_message_bus.cc
message_bus/intern/wm_message_bus_rna.cc
message_bus/intern/wm_message_bus_static.cc
ClangFormat: apply to source, most of intern Apply clang format as proposed in T53211. For details on usage and instructions for migrating branches without conflicts, see: https://wiki.blender.org/wiki/Tools/ClangFormat
2019-04-17 06:17:24 +02:00
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
WM_api.hh
WM_keymap.hh
WM_message.hh
Cleanup: Move remaining window manager headers to C++
2024-01-04 20:30:21 +01:00
WM_toolsystem.hh
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
WM_types.hh
Cleanup: Various cleanups in newly C++ headers Mostly remove unnecessary struct and typedef keywords. Move a few more small wm headers to C++ as well.
2023-08-04 23:55:14 +02:00
wm.hh
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
wm_cursors.hh
Cleanup: Various cleanups in newly C++ headers Mostly remove unnecessary struct and typedef keywords. Move a few more small wm headers to C++ as well.
2023-08-04 23:55:14 +02:00
wm_draw.hh
Cleanup: Move remaining window manager headers to C++
2024-01-04 20:30:21 +01:00
wm_event_system.hh
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
wm_event_types.hh
wm_files.hh
wm_surface.hh
Cleanup: Various cleanups in newly C++ headers Mostly remove unnecessary struct and typedef keywords. Move a few more small wm headers to C++ as well.
2023-08-04 23:55:14 +02:00
wm_window.hh
Cleanup: Move remaining window manager headers to C++
2024-01-04 20:30:21 +01:00
intern/wm_platform_support.hh
intern/wm_window_private.hh
gizmo/WM_gizmo_api.hh
gizmo/WM_gizmo_types.hh
gizmo/wm_gizmo_fn.hh
gizmo/wm_gizmo_wmapi.hh
gizmo/intern/wm_gizmo_intern.hh
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
message_bus/intern/wm_message_bus_intern.hh
message_bus/wm_message_bus.hh
use explicit file paths for CMake rather then globing, This is recommended by cmake devs. globbing vs explicit is discussed here. http://www.cmake.org/pipermail/cmake/2008-December/025694.html Practical implications are: - developers need to keep CMakeLists.txt files up to date. - Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
2010-10-23 06:05:55 +02:00
)
CMake: prepare for BLENDER_SORTED_LIBS removal No functional change, this adds LIB definition and args to cmake files. Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS' since there are many platforms/configurations that could break when changing linking order. Manually add and enable WITHOUT_SORTED_LIBS to try building without sorted libs (currently fails since all variables are empty). This check will eventually be removed. See T46725.
2019-04-14 15:18:44 +02:00
set(LIB
Cleanup: CMake: Modernize bf_blenfont dependencies Pretty straightforward - Remove any bf_blenfont paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/115365
2023-11-24 18:29:09 +01:00
PRIVATE bf::blenfont
Cleanup: CMake: Modernize bf_blenlib dependencies Pretty straightforward - Remove any blenlib paths from INC - Add a dependency though LIB Pull Request: https://projects.blender.org/blender/blender/pulls/109934
2023-07-10 22:04:18 +02:00
PRIVATE bf::blenlib
Cleanup: CMake: Modernize bf_depsgraph dependencies Pretty straightforward - Remove any bf_depsgraph paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/115422
2023-11-25 22:51:59 +01:00
PRIVATE bf::depsgraph
Cleanup: CMake: Modernize bf_dna dependencies There's quite a few libraries that depend on dna_type_offsets.h but had gotten to it by just adding the folder that contains it to their includes INC section without declaring a dependency to bf_dna in the LIB section. which occasionally lead to the lib building before bf_dna and the header being missing, while this generally gets fixed in CMake by adding bf_dna to the LIB section of the lib, however until last week all libraries in the LIB section were linked as INTERFACE so adding it in there did not resolve the build issue. To make things still build, we sprinkled add_dependencies wherever we needed it to force a build order. This diff : Declares public include folders for the bf_dna target so there's no more fudging the INC section required to get to them. Removes all dna related paths from the INC section for all libraries. Adds an alias target bf:dna to signify it has been updated to modern cmake Declares a dependency on bf::dna for all libraries that require it Removes (almost) all calls to add_dependencies for bf_dna Future work: Because of the manual dependency management that was done, there is now some "clutter" with libs depending on bf_dna that realistically don't. Example bf_intern_opencolorio itself has no dependency on bf_dna at all, doesn't need it, doesn't use it. However the dna include folder had been added to it in the past since bf_blenlib uses dna headers in some of its public headers and bf_intern_opencolorio does use those blenlib headers. Given bf_blenlib now correctly declares the dependency on bf_dna as public bf_intern_opencolorio will get the dna header directory automatically from CMake, hence some cleanup could be done for bf_intern_opencolorio Because 99% of the changes in this diff have been automated, this diff does not seek to address these issues as there is no easy way to determine why a certain dependency is in place. A developer will have to make a pass a this at some later point in time. As I'd rather not mix automated and manual labour. There are a few libraries that could not be automatically processed (ie bf_blendthumb) that also will need this manual look-over. Pull Request: https://projects.blender.org/blender/blender/pulls/109835
2023-07-10 15:07:37 +02:00
PRIVATE bf::dna
CMake: add library deps to CMakeLists.txt Tested to work on Linux and macOS. This will be enabled once all platforms are verified. See D4684
2019-04-16 06:18:52 +02:00
bf_editor_screen
Cleanup: CMake: Modernize extern_fmtlib dependencies Pretty straightforward - Remove any fmtlib paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/117787
2024-02-03 18:55:09 +01:00
PRIVATE bf::extern::fmtlib
Cleanup: CMake: Modernize bf_intern_clog dependencies Pretty straightforward - Remove any bf_intern_clog paths from INC - Add a dependency though LIB when missing context: https://devtalk.blender.org/t/cmake-cleanup/30260 Pull Request: https://projects.blender.org/blender/blender/pulls/115323
2023-11-24 17:12:24 +01:00
PRIVATE bf::intern::clog
Cleanup: CMake: Modernize bf_guardedalloc dependencies Pretty straightforward - Removes any guardedalloc paths from INC - Adds a dependency though LIB Pull Request: https://projects.blender.org/blender/blender/pulls/109925
2023-07-10 18:44:19 +02:00
PRIVATE bf::intern::guardedalloc
Refactor: Move autokeyframing functions to animrig No functional changes The following functions have been moved `autokeyframe_cfra_can_key` `autokeyframe_object` `ED_autokeyframe_object` `ED_autokeyframe_pchan` `ED_autokeyframe_property` they are all in a new file keyframing_auto.cc while the declarations are in ANIM_keyframing.cc The autokeyframe makros also have been moved Pull Request: https://projects.blender.org/blender/blender/pulls/113607
2023-10-12 15:44:58 +02:00
PRIVATE bf::animrig
Move sequencer sources from blenkernel This is first step of refactoring task T77580. Next step will be breaking up files into smaller ones. Reviewed By: sergey, brecht Differential Revision: https://developer.blender.org/D8492
2020-10-05 02:58:56 +02:00
bf_sequencer
CMake: Fix building with WITH_VULKAN_BACKEND Ghost uses vulkan in its public headers but none of the projects that depend on ghost had the vulkan headers in its includes nor did bf_intern_ghost expose this vulkan dependency itself publicly yet. bf_windowmanager also did not express its dependency on bf_intern_ghost yet used its headers. this change fixes both issues. Pull Request: https://projects.blender.org/blender/blender/pulls/112259
2023-09-12 15:07:41 +02:00
bf_intern_ghost
CMake: prepare for BLENDER_SORTED_LIBS removal No functional change, this adds LIB definition and args to cmake files. Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS' since there are many platforms/configurations that could break when changing linking order. Manually add and enable WITHOUT_SORTED_LIBS to try building without sorted libs (currently fails since all variables are empty). This check will eventually be removed. See T46725.
2019-04-14 15:18:44 +02:00
)
Cleanup: move some undo related files to C++ For continued testing in D14139. Also see T103343.
2023-01-23 00:32:39 +01:00
if(WIN32)
add_definitions(-DNOMINMAX)
endif()
Merge all changes to blenderplayer from gooseberry branch: * Allows sound playback for movies * Allow play-pause with space button * Allow displaying a position indicator with the I button
2015-06-12 11:47:37 +02:00
if(WITH_AUDASPACE)
Audaspace: fixing problems for the merge to master suggested by Campbell and Sergey. - rename WITH_EXTERNAL_AUDASPACE to WITH_SYSTEM_AUDASPACE. - rename C/PYAUDASPACE to AUDASPACE_C/PY - simplifying cmake defines and includes. - fixing include paths and enabling WITH_SYSTEM_AUDASPACE for windows. - fixing scons building. - other minor build system fixes.
2015-06-16 10:03:35 +02:00
list(APPEND INC_SYS
${AUDASPACE_C_INCLUDE_DIRS}
Merge all changes to blenderplayer from gooseberry branch: * Allows sound playback for movies * Allow play-pause with space button * Allow displaying a position indicator with the I button
2015-06-12 11:47:37 +02:00
)
CMake: quiet references to undeclared variable warnings These warnings can reveal errors in logic, so quiet them by checking if the features are enabled before using variables or by assigning empty strings in some cases. - Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs note that this may be left unset if it's not needed. - Remove BOOST/OPENVDB/VULKAN references when disable. - Define INC_SYS even when empty. - Remove PNG_INC from freetype (not defined anywhere).
2023-01-19 07:07:23 +01:00
if(WITH_SYSTEM_AUDASPACE)
list(APPEND LIB
${AUDASPACE_C_LIBRARIES}
${AUDASPACE_PY_LIBRARIES}
)
endif()
add_definitions(-DWITH_AUDASPACE)
Merge all changes to blenderplayer from gooseberry branch: * Allows sound playback for movies * Allow play-pause with space button * Allow displaying a position indicator with the I button
2015-06-12 11:47:37 +02:00
endif()
Fix error in recent change "run UserDef versioning from readfile.c" Missed moving the defines in CMake for e255040c7797 causing cycles not to be enabled.
2020-10-03 13:52:41 +02:00
if(WITH_CYCLES)
add_definitions(-DWITH_CYCLES)
endif()
patch [#19796] GLEW update by Mitchell Stokes (Moguri) GLEW update to version 1.5.1 [11-03-08] this opens room for Geometry Shader support. * - Brecht, Campbell told me you did some local changes in order to make it right in Linux. I get to you in order to know what those changes are (or feel free to commit them directly)
2009-11-21 21:36:03 +01:00
GHOST: Replace WITH_OPENGL build option Replaces it by WITH_OPENGL_BACKEND and cleanup its usage. Limits visibility of opengl enums and cases. Pull Request: https://projects.blender.org/blender/blender/pulls/109947
2023-07-11 09:17:31 +02:00
if(WITH_OPENGL_BACKEND)
add_definitions(-DWITH_OPENGL_BACKEND)
endif()
GHOST: Vulkan Backend. This adds a vulkan backend to GHOST. The code was extracted from the tmp-vulkan branch. The main difference with the original code is that GHOST isn't responsible for fallback. For Metal backend there is already an idea that the GPU module is responsible for the fallback, not the system. For Blender we target Vulkan 1.2 at the time of this patch. MoltenVK (needed to convert Vulkan calls to Metal) has been added as a separate package. This patch isn't useful for end-users, currently when starting blender with `--gpu-backend vulkan` it would crash as the `VBBackend` doesn't initialize the expected global structs in the GPU module. Validated to be working on Windows and Apple. Linux still needs to be tested. Reviewed By: fclem Differential Revision: https://developer.blender.org/D13155
2022-11-22 11:28:37 +01:00
if(WITH_VULKAN_BACKEND)
add_definitions(-DWITH_VULKAN_BACKEND)
endif()
Merge of the COLLADA GSoC branch into trunk. COLLADA code is disabled by default (it has dependencies requiring manual install). SCons and CMake builds are supported on Windows and Linux, no Mac building yet. More on building COLLADA code: http://wiki.blender.org/index.php/User:Kazanbas/Building_Collada_Branch. The detailed command log of the merge (can be useful for educational purposes): branch=https://svn.blender.org/svnroot/bf-blender/branches/soc-2009-chingachgook # collada code svn copy $branch/source/blender/collada source/blender/collada # operator svn merge -c 20401,20955,21077,24077,24079 $branch/source/blender/windowmanager/intern/wm_operators.c source/blender/windowmanager/intern/wm_operators.c # menu svn merge -c 24079 $branch/release/scripts/ui/space_info.py release/scripts/ui/space_info.py # scons svn merge -c 20398 $branch/source/blender/SConscript source/blender/SConscript svn merge -c 20398,20691,20955,22726 $branch/tools/btools.py tools/btools.py svn merge -c 20691,20955,22726 $branch/tools/Blender.py tools/Blender.py svn merge -c 20398,20692,20955 $branch/config/linux2-config.py config/linux2-config.py svn merge -c 22726 $branch/config/win64-vc-config.py config/win64-vc-config.py svn merge -c 22726 $branch/config/win32-vc-config.py config/win32-vc-config.py svn merge -c 24077 $branch/source/blender/windowmanager/SConscript source/blender/windowmanager/SConscript # cmake svn merge -c 23319,23905,24077,24158 $branch/CMakeLists.txt CMakeLists.txt svn merge -c 23319 $branch/source/blender/CMakeLists.txt source/blender/CMakeLists.txt svn merge -c 23319 $branch/source/creator/CMakeLists.txt source/creator/CMakeLists.txt svn merge -c 23319 $branch/CMake/macros.cmake CMake/macros.cmake svn merge -c 24077 $branch/source/blender/windowmanager/CMakeLists.txt source/blender/windowmanager/CMakeLists.txt
2009-10-30 16:35:50 +01:00
if(WITH_OPENCOLLADA)
add_definitions(-DWITH_COLLADA)
endif()
Add option for CMake to build libredcode, also use CODEC prefix for ffmpeg, quicktime & sndfile options.
2010-11-30 19:52:39 +01:00
if(WITH_CODEC_FFMPEG)
cmake source definitions: remove missing includes and use more strict formatting.
2011-07-17 01:01:14 +02:00
list(APPEND INC_SYS
${FFMPEG_INCLUDE_DIRS}
)
CMake: Refactor external dependencies handling This is a more correct fix to the issue Brecht was fixing in D6600. While the fix in that patch worked fine for linking it broke ASAN runtime under some circumstances. For example, `make full debug developer` would compile, but trying to start blender will cause assert failure in ASAN (related on check that ASAN is not running already). Top-level idea: leave it to CMake to keep track of dependency graph. The root of the issue comes to the fact that target like "blender" is configured to use a lot of static libraries coming from Blender sources and to use external static libraries. There is nothing which ensures order between blender's and external libraries. Only order of blender libraries is guaranteed. It was possible that due to a cycle or other circumstances some of blender libraries would have been passed to linker after libraries it uses, causing linker errors. For example, this order will likely fail: libbf_blenfont.a libfreetype6.a libbf_blenfont.a This change makes it so blender libraries are explicitly provided their dependencies to an external libraries, which allows CMake to ensure they are always linked against them. General rule here: if bf_foo depends on an external library it is to be provided to LIBS for bf_foo. For example, if bf_blenkernel depends on opensubdiv then LIBS in blenkernel's CMakeLists.txt is to include OPENSUBDIB_LIBRARIES. The change is made based on searching for used include folders such as OPENSUBDIV_INCLUDE_DIRS and adding corresponding libraries to LIBS ion that CMakeLists.txt. Transitive dependencies are not simplified by this approach, but I am not aware of any downside of this: CMake should be smart enough to simplify them on its side. And even if not, this shouldn't affect linking time. Benefit of not relying on transitive dependencies is that build system is more robust towards future changes. For example, if bf_intern_opensubiv is no longer depends on OPENSUBDIV_LIBRARIES and all such code is moved to bf_blenkernel this will not break linking. The not-so-trivial part is change to blender_add_lib (and its version in Cycles). The complexity is caused by libraries being provided as a single list argument which doesn't allow to use different release and debug libraries on Windows. The idea is: - Have every library prefixed as "optimized" or "debug" if separation is needed (non-prefixed libraries will be considered "generic"). - Loop through libraries passed to function and do simple parsing which will look for "optimized" and "debug" words and specify following library to corresponding category. This isn't something particularly great. Alternative would be to use target_link_libraries() directly, which sounds like more code but which is more explicit and allows to have more flexibility and control comparing to wrapper approach. Tested the following configurations on Linux, macOS and Windows: - make full debug developer - make full release developer - make lite debug developer - make lite release developer NOTE: Linux libraries needs to be compiled with D6641 applied, otherwise, depending on configuration, it's possible to run into duplicated zlib symbols error. Differential Revision: https://developer.blender.org/D6642
2020-01-20 18:36:19 +01:00
list(APPEND LIB
${FFMPEG_LIBRARIES}
)
Support for CMake
2008-01-03 23:20:45 +01:00
add_definitions(-DWITH_FFMPEG)
Add option for CMake to build libredcode, also use CODEC prefix for ffmpeg, quicktime & sndfile options.
2010-11-30 19:52:39 +01:00
endif()
Support for CMake
2008-01-03 23:20:45 +01:00
fix for building as a python module
2011-11-28 08:02:38 +01:00
if(WITH_HEADLESS)
add_definitions(-DWITH_HEADLESS)
Cleanup: rename WITH_X11 to WITH_GHOST_X11 Matches WITH_GHOST_{SDL|WAYLAND}
2020-05-01 11:14:50 +02:00
elseif(WITH_GHOST_X11)
add_definitions(-DWITH_GHOST_X11)
fix for building as a python module
2011-11-28 08:02:38 +01:00
endif()
Added WITH_PYTHON as a cmake option
2008-12-31 06:20:35 +01:00
if(WITH_PYTHON)
cmake source definitions: remove missing includes and use more strict formatting.
2011-07-17 01:01:14 +02:00
list(APPEND INC
../python
)
rename and negate DISABLE_PYTHON --> WITH_PYTHON
2010-10-31 05:11:39 +01:00
add_definitions(-DWITH_PYTHON)
Fix T82675: Crash on exit when Blender is built as a Python module
2021-01-28 04:38:08 +01:00
if(WITH_PYTHON_MODULE)
add_definitions(-DWITH_PYTHON_MODULE)
endif()
Added WITH_PYTHON as a cmake option
2008-12-31 06:20:35 +01:00
endif()
Added the svn revision number to the splash screen (when buildinfo is enabled). Also fixed cmake so buildinfo works. Note to all: ** Please mention the revision number when making a bug report **
2010-01-08 06:51:51 +01:00
if(WITH_BUILDINFO)
rename NAN_BUILDINFO --> WITH_BUILDINFO
2011-08-22 18:54:26 +02:00
add_definitions(-DWITH_BUILDINFO)
Added the svn revision number to the splash screen (when buildinfo is enabled). Also fixed cmake so buildinfo works. Note to all: ** Please mention the revision number when making a bug report **
2010-01-08 06:51:51 +01:00
endif()
Support for CMake
2008-01-03 23:20:45 +01:00
NDOF: compile 3D mouse code only if WITH_INPUT_NDOF When WITH_INPUT_NDOF is disabled, 3D mouse handling code is removed from: - GHOST (was mostly done, finished the job) - window manager - various editors - RNA - keymaps The input tab of user prefs does not show 3D mouse settings. Key map editor does not show NDOF mappings. DNA does not change. On my Mac the compiled binary is 42KB smaller after this change. It runs fine WITH_INPUT_NDOF on or off.
2016-08-18 06:21:55 +02:00
if(WITH_INPUT_NDOF)
add_definitions(-DWITH_INPUT_NDOF)
endif()
Cleanup: set WITH_INPUT_IME=OFF when unsupported This avoids having to do platform checks before checking WITH_INPUT_IME.
2023-10-18 13:04:25 +02:00
if(WITH_INPUT_IME)
add_definitions(-DWITH_INPUT_IME)
Input Method Editor (IME) support for text buttons Original patch by @random (D765) with some minor work done by @campbell and me. At this place, I'd like call out a number of people who were involved and deserve a big "Thank you!": * At the first place @randon who developed and submitted the patch * The Blendercn community which helped a lot with testing - espacially * @yuzukyo, @leon_cheung and @kjym3 * @campbellbarton, @mont29 and @sergey for their help and advises during * review * @ton who realized the importance of this early on and asked me for * reviewing We are still not finished, as this is only the first part of the implementaion, but there's more to come!
2014-12-07 00:58:17 +01:00
endif()
Compositor: Rename compositor build option Currently, the compositor can be disabled using the WITH_COMPOSITOR build option. Since, we intent to always build the realtime compositor, we need to make the distinction between both compositors clear. So this patch renames the option to WITH_COMPOSITOR_CPU. Additionally, the check for the option was moved inside the compositor modules' own CMake file in preparation for the realtime compositor code. Differential Revision: https://developer.blender.org/D15622 Reviewed By: Jeroen Bakker, Ray Molenkamp
2022-08-09 15:59:56 +02:00
if(WITH_COMPOSITOR_CPU)
CMake: add library deps to CMakeLists.txt Tested to work on Linux and macOS. This will be enabled once all platforms are verified. See D4684
2019-04-16 06:18:52 +02:00
list(APPEND LIB
bf_compositor
)
Compositor: Rename compositor build option Currently, the compositor can be disabled using the WITH_COMPOSITOR build option. Since, we intent to always build the realtime compositor, we need to make the distinction between both compositors clear. So this patch renames the option to WITH_COMPOSITOR_CPU. Additionally, the check for the option was moved inside the compositor modules' own CMake file in preparation for the realtime compositor code. Differential Revision: https://developer.blender.org/D15622 Reviewed By: Jeroen Bakker, Ray Molenkamp
2022-08-09 15:59:56 +02:00
add_definitions(-DWITH_COMPOSITOR_CPU)
fix for building without the compositor
2012-07-17 12:19:47 +02:00
endif()
VR: Initial Virtual Reality support - Milestone 1, Scene Inspection NOTE: While most of the milestone 1 goals are there, a few smaller features and improvements are still to be done. Big picture of this milestone: Initial, OpenXR-based virtual reality support for users and foundation for advanced use cases. Maniphest Task: https://developer.blender.org/T71347 The tasks contains more information about this milestone. To be clear: This is not a feature rich VR implementation, it's focused on the initial scene inspection use case. We intentionally focused on that, further features like controller support are part of the next milestone. - How to use? Instructions on how to use this are here: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test These will be updated and moved to a more official place (likely the manual) soon. Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC headsets don't support the OpenXR standard yet and hence, do not work with this implementation. --------------- This is the C-side implementation of the features added for initial VR support as per milestone 1. A "VR Scene Inspection" Add-on will be committed separately, to expose the VR functionality in the UI. It also adds some further features for milestone 1, namely a landmarking system (stored view locations in the VR space) Main additions/features: * Support for rendering viewports to an HMD, with good performance. * Option to sync the VR view perspective with a fully interactive, regular 3D View (VR-Mirror). * Option to disable positional tracking. Keeps the current position (calculated based on the VR eye center pose) when enabled while a VR session is running. * Some regular viewport settings for the VR view * RNA/Python-API to query and set VR session state information. * WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data * wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU context) * DNA/RNA for management of VR session settings * `--debug-xr` and `--debug-xr-time` commandline options * Utility batch & config file for using the Oculus runtime on Windows. * Most VR data is runtime only. The exception is user settings which are saved to files (`XrSessionSettings`). * VR support can be disabled through the `WITH_XR_OPENXR` compiler flag. For architecture and code documentation, see https://wiki.blender.org/wiki/Source/Interface/XR. --------------- A few thank you's: * A huge shoutout to Ray Molenkamp for his help during the project - it would have not been that successful without him! * Sebastian Koenig and Simeon Conzendorf for testing and feedback! * The reviewers, especially Brecht Van Lommel! * Dalai Felinto for pushing and managing me to get this done ;) * The OpenXR working group for providing an open standard. I think we're the first bigger application to adopt OpenXR. Congratulations to them and ourselves :) This project started as a Google Summer of Code 2019 project - "Core Support of Virtual Reality Headsets through OpenXR" (see https://wiki.blender.org/wiki/User:Severin/GSoC-2019/). Some further information, including ideas for further improvements can be found in the final GSoC report: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report Differential Revisions: D6193, D7098 Reviewed by: Brecht Van Lommel, Jeroen Bakker
2020-03-17 20:20:55 +01:00
if(WITH_XR_OPENXR)
add_definitions(-DWITH_XR_OPENXR)
Cleanup: Split up Window-Manager VR file (and related changes) Splits up wm_xr.c into multiple files in their own folder: source/blender/windowmanager/xr. So this matches how the message bus and gizmo code have their own folder and files. This allows better structuring and should make the code scale better. I rather do this early on than to wait until we end up with a single, huge file. Also improves a bit how data is prepared and updated for drawing.
2020-04-04 02:17:49 +02:00
list(APPEND INC
xr
)
VR: Initial Virtual Reality support - Milestone 1, Scene Inspection NOTE: While most of the milestone 1 goals are there, a few smaller features and improvements are still to be done. Big picture of this milestone: Initial, OpenXR-based virtual reality support for users and foundation for advanced use cases. Maniphest Task: https://developer.blender.org/T71347 The tasks contains more information about this milestone. To be clear: This is not a feature rich VR implementation, it's focused on the initial scene inspection use case. We intentionally focused on that, further features like controller support are part of the next milestone. - How to use? Instructions on how to use this are here: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test These will be updated and moved to a more official place (likely the manual) soon. Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC headsets don't support the OpenXR standard yet and hence, do not work with this implementation. --------------- This is the C-side implementation of the features added for initial VR support as per milestone 1. A "VR Scene Inspection" Add-on will be committed separately, to expose the VR functionality in the UI. It also adds some further features for milestone 1, namely a landmarking system (stored view locations in the VR space) Main additions/features: * Support for rendering viewports to an HMD, with good performance. * Option to sync the VR view perspective with a fully interactive, regular 3D View (VR-Mirror). * Option to disable positional tracking. Keeps the current position (calculated based on the VR eye center pose) when enabled while a VR session is running. * Some regular viewport settings for the VR view * RNA/Python-API to query and set VR session state information. * WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data * wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU context) * DNA/RNA for management of VR session settings * `--debug-xr` and `--debug-xr-time` commandline options * Utility batch & config file for using the Oculus runtime on Windows. * Most VR data is runtime only. The exception is user settings which are saved to files (`XrSessionSettings`). * VR support can be disabled through the `WITH_XR_OPENXR` compiler flag. For architecture and code documentation, see https://wiki.blender.org/wiki/Source/Interface/XR. --------------- A few thank you's: * A huge shoutout to Ray Molenkamp for his help during the project - it would have not been that successful without him! * Sebastian Koenig and Simeon Conzendorf for testing and feedback! * The reviewers, especially Brecht Van Lommel! * Dalai Felinto for pushing and managing me to get this done ;) * The OpenXR working group for providing an open standard. I think we're the first bigger application to adopt OpenXR. Congratulations to them and ourselves :) This project started as a Google Summer of Code 2019 project - "Core Support of Virtual Reality Headsets through OpenXR" (see https://wiki.blender.org/wiki/User:Severin/GSoC-2019/). Some further information, including ideas for further improvements can be found in the final GSoC report: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report Differential Revisions: D6193, D7098 Reviewed by: Brecht Van Lommel, Jeroen Bakker
2020-03-17 20:20:55 +01:00
list(APPEND SRC
WM: move to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/110292
2023-07-20 22:12:29 +02:00
xr/intern/wm_xr.cc
xr/intern/wm_xr_action.cc
xr/intern/wm_xr_actionmap.cc
xr/intern/wm_xr_draw.cc
xr/intern/wm_xr_operators.cc
xr/intern/wm_xr_session.cc
Cleanup: Split up Window-Manager VR file (and related changes) Splits up wm_xr.c into multiple files in their own folder: source/blender/windowmanager/xr. So this matches how the message bus and gizmo code have their own folder and files. This allows better structuring and should make the code scale better. I rather do this early on than to wait until we end up with a single, huge file. Also improves a bit how data is prepared and updated for drawing.
2020-04-04 02:17:49 +02:00
Cleanup: Move remaining window manager headers to C++
2024-01-04 20:30:21 +01:00
xr/wm_xr.hh
xr/intern/wm_xr_intern.hh
VR: Initial Virtual Reality support - Milestone 1, Scene Inspection NOTE: While most of the milestone 1 goals are there, a few smaller features and improvements are still to be done. Big picture of this milestone: Initial, OpenXR-based virtual reality support for users and foundation for advanced use cases. Maniphest Task: https://developer.blender.org/T71347 The tasks contains more information about this milestone. To be clear: This is not a feature rich VR implementation, it's focused on the initial scene inspection use case. We intentionally focused on that, further features like controller support are part of the next milestone. - How to use? Instructions on how to use this are here: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test These will be updated and moved to a more official place (likely the manual) soon. Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC headsets don't support the OpenXR standard yet and hence, do not work with this implementation. --------------- This is the C-side implementation of the features added for initial VR support as per milestone 1. A "VR Scene Inspection" Add-on will be committed separately, to expose the VR functionality in the UI. It also adds some further features for milestone 1, namely a landmarking system (stored view locations in the VR space) Main additions/features: * Support for rendering viewports to an HMD, with good performance. * Option to sync the VR view perspective with a fully interactive, regular 3D View (VR-Mirror). * Option to disable positional tracking. Keeps the current position (calculated based on the VR eye center pose) when enabled while a VR session is running. * Some regular viewport settings for the VR view * RNA/Python-API to query and set VR session state information. * WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data * wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU context) * DNA/RNA for management of VR session settings * `--debug-xr` and `--debug-xr-time` commandline options * Utility batch & config file for using the Oculus runtime on Windows. * Most VR data is runtime only. The exception is user settings which are saved to files (`XrSessionSettings`). * VR support can be disabled through the `WITH_XR_OPENXR` compiler flag. For architecture and code documentation, see https://wiki.blender.org/wiki/Source/Interface/XR. --------------- A few thank you's: * A huge shoutout to Ray Molenkamp for his help during the project - it would have not been that successful without him! * Sebastian Koenig and Simeon Conzendorf for testing and feedback! * The reviewers, especially Brecht Van Lommel! * Dalai Felinto for pushing and managing me to get this done ;) * The OpenXR working group for providing an open standard. I think we're the first bigger application to adopt OpenXR. Congratulations to them and ourselves :) This project started as a Google Summer of Code 2019 project - "Core Support of Virtual Reality Headsets through OpenXR" (see https://wiki.blender.org/wiki/User:Severin/GSoC-2019/). Some further information, including ideas for further improvements can be found in the final GSoC report: https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report Differential Revisions: D6193, D7098 Reviewed by: Brecht Van Lommel, Jeroen Bakker
2020-03-17 20:20:55 +01:00
)
endif()
CMake: prepare for BLENDER_SORTED_LIBS removal No functional change, this adds LIB definition and args to cmake files. Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS' since there are many platforms/configurations that could break when changing linking order. Manually add and enable WITHOUT_SORTED_LIBS to try building without sorted libs (currently fails since all variables are empty). This check will eventually be removed. See T46725.
2019-04-14 15:18:44 +02:00
blender_add_lib_nolist(bf_windowmanager "${SRC}" "${INC}" "${INC_SYS}" "${LIB}")
Fix compilation error when building from scratch Make sure the DNA offset files is ready at a time bf_windowmanager need it.
2020-11-06 13:49:56 +01:00
RNA: Generate property declerations header, solving msg-bus C++ incompatibility Lets `makesrna` generate a `RNA_prototypes.h` header with declarations for all RNA properties. This can be included in regular source files when needing to reference RNA properties statically. This solves an issue on MSVC with adding such declarations in functions, like we used to do. See 800fc1736748. Removes any such declarations and the related FIXME comments. Reviewed By: campbellbarton, LazyDodo, brecht Differential Revision: https://developer.blender.org/D13837
2022-03-14 16:39:42 +01:00
# RNA_prototypes.h
add_dependencies(bf_windowmanager bf_rna)
IO: Add support for multiple drag-n-drop files There are operators in Blender that allow the user to import multiple files at the same time, however this functionality is only implemented when importing with blender's file browser, drag and drop files only takes first selected file. The patch adds support for drag and drop multiple files. Notes: * The files are filtered according to the extension of the first selected file. * Not all operators that import files support importing multiple files, so they will still import one. * Changes must be made to allow importers to read all file paths. This will be used in upcoming drag & drop import. Pull Request: https://projects.blender.org/blender/blender/pulls/107230
2023-12-12 18:46:12 +01:00
if(WITH_GTESTS)
Cleanup: quite unused variable warning with CMake
2023-12-17 06:04:34 +01:00
set(TEST_INC
)
IO: Add support for multiple drag-n-drop files There are operators in Blender that allow the user to import multiple files at the same time, however this functionality is only implemented when importing with blender's file browser, drag and drop files only takes first selected file. The patch adds support for drag and drop multiple files. Notes: * The files are filtered according to the extension of the first selected file. * Not all operators that import files support importing multiple files, so they will still import one. * Changes must be made to allow importers to read all file paths. This will be used in upcoming drag & drop import. Pull Request: https://projects.blender.org/blender/blender/pulls/107230
2023-12-12 18:46:12 +01:00
set(TEST_SRC
intern/wm_dragdrop_test.cc
)
Tests: add option to build one binary per GTest file Bundling many tests in a single binary reduces build time and disk space usage, but is less convenient for running individual tests command line as filter flags need to be used. This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per source file. Note that enabling this option requires a significant amount of disk space. Due to refactoring, the resulting ctest names are a bit different than before. The number of tests is also a bit different depending if this option is used, as one uses gtests discovery and the other is organized purely by filename, which isn't always 1:1. Co-authored-by: Sergey Sharybin <sergey@blender.org> Pull Request: https://projects.blender.org/blender/blender/pulls/114604
2024-01-03 18:35:50 +01:00
blender_add_test_suite_lib(windowmanager "${TEST_SRC}" "${INC};${TEST_INC}" "${INC_SYS}" "${LIB}")
IO: Add support for multiple drag-n-drop files There are operators in Blender that allow the user to import multiple files at the same time, however this functionality is only implemented when importing with blender's file browser, drag and drop files only takes first selected file. The patch adds support for drag and drop multiple files. Notes: * The files are filtered according to the extension of the first selected file. * Not all operators that import files support importing multiple files, so they will still import one. * Changes must be made to allow importers to read all file paths. This will be used in upcoming drag & drop import. Pull Request: https://projects.blender.org/blender/blender/pulls/107230
2023-12-12 18:46:12 +01:00
endif()