[llvm-commits] [Review request] CMake/MSVS: Support for the target "check"

[Daniel Dunbar]

Hi Takumi,

This patch looks good to me.

 - Daniel

On Wed, Nov 24, 2010 at 1:39 AM, NAKAMURA Takumi <geek4civic at gmail.com> wrote:
> Hello, Oscar.
>
> I apologize to you, I supposed you sent the last mail directly to me by mistake.
> (The message does not have "To/Cc: llvm-commits", but I found later
> "Newsgroup: gmane.comp.compilers.llvm.cvs")
>
> Here is 2nd patch. Please take a look.
>
>  - Define "RUNTIME_BUILD_MODE" in /CMakeLists.txt.
>    (To integrate to clang/test/CMakeLists.txt)
>  - Respect MSVC_IDE.
>
> 2010/11/24 Óscar Fuentes <ofv at wanadoo.es>:
>>> I tried on nmake, but weird nmake doesn't launch tests.
>>> I won't investigate anything on nmake, it must not be my task! :p
>>> I would like to give someone tasks for nmake. :)
>>
>> I use nmake (and JOM, an nmake clone) but don't do testing. The support
>> for testing on the cmake build was implemented by somebody else. I know
>> almost nothing about it.
>>
>>> # imfo: who uses nmake for clang/llvm!
>>
>> I do. It is really useful. And JOM supports parallel builds on a similar
>> way that gmake does. When you are working with cmake, for most ordinary
>> applications you can assume that nmake is just another `make'. Actually,
>> you need to worry about this two cases when writing cmake scripts that
>> have to know the exact place where build products are placed: make-based
>> build systems (build type is known when cmake is invoked) and ide-based
>> build-systems (build type is selected by the user when the he starts the
>> build and the output directory depend on that selection).
>
> I supposed "JOM" might be a wrapper or something and I did not know.
> I will try JOM in near future, thank you.
> In fact, I was tired to build cmake/llvm with MS nmake. :(
>
> I will report nmake issue later.
> Or, Oscar, would you like to join tweaking tests on cmake? ;)
>
>>> I assume;
>>>
>>>   - ${CMAKE_BUILD_TYPE} should be empty on msvs/vcbuild/msbuild.
>>>   - ${CMAKE_CFG_INTDIR} might be "." on others.
>>>
>>> I will rewrite my patch as below similar;
>>>
>>> if CMAKE_BUILD_TYPE is not empty
>>>   BUILD_MODE obeys it.
>>> elsif CMAKE_CFG_INTDIR is not "."
>>>   BUILD_MODE obeys it. (it might be "$(...)")
>>> else
>>>   warn "Unittests cannot be executed"
>>> endif
>>
>> Don't assume that CMAKE_BUILD_TYPE will be empty or not depending on the
>> tool used for the build (IDE/make). Testing CMAKE_CFG_INTDIR is
>> safer. So do this:
>>
>> if( CMAKE_CFG_INTDIR STREQUAL "." )
>>  ... Use CMAKE_CFG_INTDIR
>> else()
>>  ... CMAKE_CFG_INTDIR is not required
>> endif()
>>
>> Please note that CMAKE_BUILD_TYPE is not needed for knowing the
>> directory where build products are placed when using make-based build
>> systems. Always using CMAKE_CFG_INTDIR should be safe, as
>> tests/CMakeLists.txt already does:
>>
>> set(LLVM_TOOLS_DIR "${LLVM_TOOLS_BINARY_DIR}/${CMAKE_CFG_INTDIR}")
>>
>> That expands to the correct directory when you are using an IDE or a
>> `make'.
>
> Note that BUILD_MODE is required by Unittests.
> This is the reason why I have been tweaking BUILD_MODE.
> I don't forget PR8438.
>
>
> ...Takumi
>