* 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>
* Legacy cleanup, part 2
There are still things that can be removed, those will be likely done in part three:
`The Return of the Cleanup` :)
Signed-off-by: nemerle <96597+nemerle@users.noreply.github.com>
* Fix windows build
Somehow there were some unfixed errors from enabled warnings?
I'm unsure if I've pulled repo in unstable state, or those were somehow
missed.
Signed-off-by: nemerle <96597+nemerle@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>
* Updating the DefaultProject template to not insert the project-path parameter into the VS Debugger Arguments for any applications
Added project-path injection directly within the LauncherUnified and AssetBuilder cmake scripts where their targets are defined
* Removing the add_vs_debugger_arguments call from the AutomatedTesting CMakeLists.txt
* should pickup the external directories registered by the project
* Add support for AzTest and AzTestRunner in the SDK
* missing IMPORT_LIB
* Moved where .Assets targets get generated so they are visible in the SDK
* generate the Directory.Build.props in the right path
* excluding target on platforms that dont support it
* 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::"
Esteban Papp
lumberyard-employee-dm
Artur K
pappeste
Steve Pham
Chris Galvan
mgwynn
nvsickle
Gene Walters
SJ
amzn-mgwynn
Olex Lozitskiy
karlberg
moudgils