Gregor Jasny 10c9c73d58 Xcode: Control emission of EFFECTIVE_PLATFORM_NAME
When building with multiple SDKs within one project Xcode requires
the usage of ${EFFECTIVE_PLATFORM_NAME} to put temporary and build
outout into separate directories. For example an iOS device and
simulator build use two different SDKs (iphoneos and iphonesimulator).

In the past cmake tries to detect embedded toolchains that could
possibly use simulators and emitted EFFECTIVE_PLATFORM_NAME (EPN)
at the proper locations. In #16253 Mark noticed that if he
uses macosx and iphoneos in combination the necessary EPN is not
emitted. This is because CMake by default assumes macosx SDK which
does not trigger EPN emission.

The fist naive approach - enabling EPN unconditionally revealed that
then the EPN leaks into generator expressions like $<TARGET_FILE:xxx>
which might be a regression and thus is unacceptable.

The next approach was to add an CMake property to enable EPN emission
unconditionally. This solved the reported problem.

But the EPN leakage also happened for the embedded toolchains already
without anyone noticing. So the control property was turned into a
tri-state one:

 * No definition: EPN is activated for embedded toolchains like before
 * ON: EPN is always emitted
 * OFF: EPN is never emitted

That approach gives the user the chance to disable EPN for embedded
toolchains and restores generator expression functionality for those.

Closes: #16253
2017-01-20 13:51:48 -05:00
..
2016-09-09 11:42:35 -04:00
2016-07-28 00:43:04 +02:00
2016-07-28 00:43:04 +02:00
2016-07-28 00:43:04 +02:00
2016-07-28 00:43:04 +02:00
2016-07-28 00:43:04 +02:00

If you think about adding a new testcase then here is a small checklist you
can run through to find a proper place for it. Go through the list from the
beginning and stop once you find something that matches your tests needs,
i.e. if you will test a module and only need the configure mode use the
instructions from section 2, not 3.

1. Your testcase can run in CMake script mode, i.e. "cmake -P something"

Put your test in Tests/CMakeTests/ directory as a .cmake.in file. It will be
put into the test binary directory by configure_file(... @ONLY) and run from
there. Use the AddCMakeTest() macro in Tests/CMakeTests/CMakeLists.txt to add
your test to the test runs.

2. Your test needs CMake to run in configure mode, but will not build anything

This includes tests that will build something using try_compile() and friends,
but nothing that expects add_executable(), add_library(), or add_test() to run.

If the test configures the project only once and it must succeed then put it
into the Tests/CMakeOnly/ directory.  Create a subdirectory named like your
test and write the CMakeLists.txt you need into that subdirectory. Use the
add_CMakeOnly_test() macro from Tests/CMakeOnly/CMakeLists.txt to add your
test to the test runs.

If the test configures the project with multiple variations and verifies
success or failure each time then put it into the Tests/RunCMake/ directory.
Read the instructions in Tests/RunCMake/CMakeLists.txt to add a test.

3. If you are testing something from the Modules directory

Put your test in the Tests/Modules/ directory. Create a subdirectory there
named after your test. Use the ADD_TEST_MACRO macro from Tests/CMakeLists.txt
to add your test to the test run. If you have put your stuff in
Tests/Modules/Foo then you call it using ADD_TEST_MACRO(Module.Foo Foo).

4. You are doing other stuff.

Find a good place ;) In doubt mail to cmake-developers@cmake.org and ask for
advise.