* Implemented the RFC to allow projects to need to specify the Gems
Projects no longer need to specify CMake Targets to associate a Gem
variant with.
In order to associate a CMake Target with a gem variant a new
`ly_set_gem_variant_to_load` function has been added that maps CMake
Targets -> Gem Variants.
This allows CMake Targets to self describe which gem variants they
desire to build and load
This implementation is backwards compatible:
The `ly_enable_gems` function still accepts the TARGETS and VARIANTS
arguments which it will forward to the new `ly_set_gem_variant_to_load`
function to allow the input Targets to be associated with input Gem
Variants
This changes fixes the issue with gems that are required by an
Application regardless of the Project in use, not replicating it's
"requiredness" to the SDK layout
Fixes#3430
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added an LY_PROJECT_NAME property to the Launcher targets
The `ly_enable_gems_delayed` now command queries the LY_PROJECT_NAME property
associated with each target to determine if the gems being enabled are
match the project the target is associated with.
In this case the target only adds dependencies if the gems is being enabled
without a specific project or if the gems is being enabled for the
matching project.
If the LY_PROJECT_NAME property is not set for target, it indicates the
gems for each project can be added as dependencies to the target.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* The INSTALL step now forwards the LY_PROJECT_NAME property for a target
The Install_common.cmake has been updated to support configuring
TARGET_PROPERTIES into the generated CMakeLists.txt for install targets.
Furthermore the indentation of the generated CMakeLists.txt has been
normalized to help with readability
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Updating the Atom_Bootstrap CMakeLists.txt to enable the Atom_Bootstrap Gem
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added a deprecation message to ly_enable_gems when supplying TARGETS and
VARIANTS
Added a define_property call for the LY_PROJECT_NAME target property
Removed the .Builders alias for the PrefabBuilder and renamed the
GEM_MODULE target o PrefabBuilder.Builders.
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Removed superflous space from AutomatedTesting Gem CMakeLists.txt
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Create RUN target as helpers for the project-centric workflow
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* typo fix
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
* rename target as "<target>.Imported" and create "<target>" as the metatarget that is used for debugging and building in o3de
Signed-off-by: Esteban Papp <81431996+amznestebanpapp@users.noreply.github.com>
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
Esteban Papp
lumberyard-employee-dm
Steve Pham
pappeste
Nicholas Lawson
phistere
alexpete