Stephen Kelly b80557c7bd file(GENERATE): Evaluate early to allow generating source files
The evaluation files must be known before cmTargetTraceDependencies
attempts to find them, but we must actually generate the files after
cmTargetTraceDependencies, as that can add to target SOURCES.  The
limitation is that the generated output name must not depend on the
SOURCES of a target if the generated file is used by that target.

Mark the output files as GENERATED so that trace dependencies does
not expect them to already exist in the filesystem.

Move the invokation of ForceLinkerLanguage in the Generate logic
to after the generated file names are known.  ForceLinkerLanguage
tries to determine the sources of a target (in order to determine
an already-known language) and otherwise fails to get information
about the generated file.

Test that the output of file(GENERATE) can be used as a target source
file and that accessing the target SOURCES in the name of the output
file is an error.  Accessing the TARGET_OBJECTS would be a similar
error if it was legal to use that generator expression in this
context.  That is not currently possible and is a different error
condition, so test the current error output as a reminder to change
the expected output if that becomes possible in the future.  Test
that generated rule files resulting from cmTargetTraceDependencies
appear in the SOURCES generated in the output file.
2014-11-12 22:36:45 +01:00
..
2014-09-16 09:06:29 -04:00
2014-09-16 09:06:29 -04:00
2014-09-16 09:06:29 -04:00
2013-10-08 08:37:50 -04:00
2014-08-20 10:19:49 -04:00
2014-11-10 10:43:10 -05: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.