alias INTERFACE LIBRARY targets.
This was causing the dependent Atom_AtomBridge sub gems from not being
found when generating the cmake_dependencies.*.setreg file containing
the list of gem modules to load
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Final update copyright headers to reference license files at the repo root
Signed-off-by: spham <spham@amazon.com>
* Fix copyright validator unit tests to support the stale O3DE header scenario
Signed-off-by: spham <spham@amazon.com>
* fix for some install generation issues around ly_enable_gems
* setting the right SettingsRegistry path for imported targets
* missing "include" in the exported target
* Fixed issue with the GEM_FILE argument being specified in replicated ly_enable_gems call
If the original call to `ly_enable_gems` supplied an argument for GEM_FILE, then in the replicated `ly_enable_gems` call in the install layout CMakeLists.txt, supplied both the GEMS and GEM_FILE argument which are mutually exclusive, due to the `ly_enable_gems` function populating the `ly_enable_gems_GEMS` variable from the content of the `ly_enable_gems_GEM_FILE` file.
Furthermore the install layout does not copy over the file that was parsed by the GEM_FILE argument, so it would point to a non-existent file the install layout.
* Fixed comment
Co-authored-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Adding a Tools and Builders variant to the DccScriptingInterface gem target to allow it to be used as a gem in the AtomTest project
* Adding support to ly_create_alias to be able to specify an alias with no
dependencies
Updated the SettingsRegistry.cmake generation code to support generating
a Gem target entry in the cmake_dependencies.*.setreg file when an
interface library with no dependencies is parsed
* Fixed generation of Monolithic builds StaticModules.inl
A project's gem module RUNTIME_DEPENDENCIES were not visited to
determine any dependent gem modules that needed to load.
Therefore the CreateStaticModules function were missing
CreateModuleClass_* function calls required initialize the gem's AZ::Module
derived class in monolithic builds
* Removed the logic to strip the Gem:: and Project:: prefix from the Server Launcher gem dependencies
When associating gem dependencies with the server target there was CMake logic left over in it to strip the beginning of the target name if it began with "Gem::" or "Project::"
which are to be seen as sub gem roots as a workaround for detecting the
location of the "gem" root for the Atom/AtomLyIntegration GEM_MODULE targets
Removed the logic in the SettingsRegistry.cmake for reading a
"gem_module_roots" key from the gem.json file in order to determine the
root of the Atom and Atom LyIntegration sub gem modules
cmake_dependencies.<prefix>.<target>.setreg files to detect the nearest
gem module root for a cmake target that has been marked with the
GEM_MODULE property.
The list of gem module roots are made up of the gem.json location + list
of paths in the gem.json "gem_module_roots" JSON array if it exist
Removed the EngineFinder.cmake file from the Engine cmake directory as it is only needed in a Project
Added an EngineJson.cmake which reads the "external_subdirectories" list from the engine.json file and calls add_subdirectory on it
Re-ordered the population of the generated gem dependency list to prepend the dependencies before the dependent targets
lumberyard-employee-dm
Steve Pham
Esteban Papp
pappeste
Nicholas Lawson
phistere
alexpete