Re: [cmake-developers] RFC: LLVM community CMake documentation

[Dan Liew]

Hi Chris,

Thanks for doing this. I've had a quick scan and I have a few minor comments.

# Scripting overview

This is personal preference but I don't like ``add_definitions()`` due
to its global behaviour so I think its use should be discouraged. I
much prefer ``target_compile_definitions()`` which isn't global.

# Dereferencing

One "Gotcha" I think that is worth mentioning is implicit derefencing
of variables in ``if()`` conditionals

for example

```
if ("${SOME_VAR}" STREQUAL "MSVC")
```

behaves very strangely because CMake will implicitly dereference
"MSVC" (as if it was "${MSVC}") where as someone reading the code
probably thinks that it is trying to check if the contents of the
SOME_VAR as a string are "MSVC".

This behaviour is prevented by setting CMP0054 to NEW but this was
only introduced with CMake 3.1 and I don't think that's LLVM's minimum
version so developers might hit this issue. Run ``cmake --help-policy
CMP0054`` for more details.

A hacky work around I employ is to write conditionals like that like this

```
if ("X${SOME_VAR}" STREQUAL "XMSVC")
```

It's not good though...

# Scope

You don't mention "GLOBAL" properties. IIRC LLVM's CMake code uses
these so it might be worth mentioning these

# LLVM specific macros/functions

LLVM's CMake code pretty much avoids using many of the standard CMake
commands for declaring targets favouring its own (sometimes
confusingly named, e.g. add_llvm_library Vs. llvm_add_library) which I
sometime find quite confusing. Seeing as this guide is aimed at LLVM
developers I think this document (or an accompanying document) should
describe these macros/functions.

Thanks,
Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] add_custom_command() OUTPUT does not accept generator expressions, why?

[Dan Liew]

Hi,

On 28 March 2016 at 15:05, Brad King <brad.k...@kitware.com> wrote:
> On 03/27/2016 06:11 AM, Dan Liew wrote:
>> OUTPUT does not accept generator expressions, why?
>
> It hasn't been implemented.  At least at one time it would have been
> very hard to implement.  I'm not sure now because there has been a lot
> of refactoring since I last looked at it.
>
> There is some discussion here:
>
>  https://cmake.org/Bug/view.php?id=13840
>  https://cmake.org/Bug/view.php?id=12877#c28315
>
>> If I can't use generator expressions with ``OUTPUT``, how am I
>> supposed to output a file into the build directory of a target?
>
> Unfortunately it is not possible to do cleanly without fixing the
> above.  Approximations include:
>
> * Use a POST_BUILD command on the target instead.
>
> * Make the OUTPUT a timestamp file and generate the real output
>   as a side effect.
>
> If anyone is interested in trying to implement generator expressions
> for custom command outputs, I can provide more details to get started.

Thanks for the info Brad. I wish I had time to look into this but I
don't so for now I'll just work around it.

Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Dan Liew]

On 3 March 2016 at 22:02, Nils Gladitz <nilsglad...@gmail.com> wrote:
> On 03.03.2016 22:57, Dan Liew wrote:
>>
>> Hi,
>>
>> I noticed recently is you do something like this
>>
>> add_executable(foo a.cpp b.cpp)
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
>> set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")
>>
>> then the flags that end up being passed to the compiler during linking
>> are like this.
>>
>> gcc -g -O0 -fopenmp;-static
>>
>> It looks like when using the property with APPEND it becomes a list
>> but when emitted the list isn't expanded properly. I noticed this
>> using CMake 3.4.3 using the "Unix Makefile" generator.
>>
>> Is this intentional or is this a bug?
>
>
> LINK_FLAGS is not a list property; flags have to be whitespace separated.
> You can use APPEND_STRING instead of APPEND for this.

Thanks for this. Shouldn't the fact that ``LINK_FLAGS`` is a string
property and not a list property be in the ``cmake-properties``
documentation? The version of the documentation for my version of
CMake (3.4.3) doesn't say what the property type is.

Thanks,
Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Dan Liew]

Hi,

I noticed recently is you do something like this

add_executable(foo a.cpp b.cpp)
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")

then the flags that end up being passed to the compiler during linking
are like this.

gcc -g -O0 -fopenmp;-static

It looks like when using the property with APPEND it becomes a list
but when emitted the list isn't expanded properly. I noticed this
using CMake 3.4.3 using the "Unix Makefile" generator.

Is this intentional or is this a bug?

Thanks,
Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Obtaining header file dependencies of a source file manually

[Dan Liew]

>> There is an alternative which I suggested in the post. Have CMake
>> determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
>> at configure time and spit that into the build files of the generator
>> (that would work for any generator). Then have any changes made to the
>> files passed to ``IMPLICIT_DEPENDS`` trigger a reconfigure so that the
>> dependencies can be recomputed.
>
> Perhaps, but after regenerating the project the build tool will not
> re-load the build files and start building again.  That will take
> an additional invocation.  The number of iterations required is
> bounded only by the depth of dependency chains.

I don't understand what you mean. What do you mean by "build tool" here?
I also don't see why you would need to reconfigure multiple times.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

> I fail to see why that should not work. Producing LLVM bitcode from
> C++ with Clang is just adding -emit-llvm flag, right? So, why can't
> the SuperBuild configure the child build to use Clang and this flag?
> And Bob's your uncle...

Hmm, to be honest I hadn't tried. It works better than expected but...

The problem for this particular project is that it doesn't file a very
standard compilation process. It compiles to LLVM IR, then to LLVM
bitcode and then it invokes and external program to generate source
files with the LLVM bitcode embedded in specially named arrays these
generated source files then are compiled along with other sources into
the projects main library. If I made the external project create
OBJECT libraries rather than regular libraries then that might work
but when I add the ``-emit-llvm`` flag to CMAKE_C_FLAGS things start
breaking..., e.g.

```
include(CheckCCompilerFlag)
CHECK_C_COMPILER_FLAG("-g" SUPPORTS_DEBUG)
```

Checking this compiler flag fails if CMAKE_C_FLAGS contains
``-emit-llvm`` due to linking errors.

I also need a way of communicating to the outside world where the
object files are as they are the final output. Using ``add_library(foo
OBJECT ...)`` is just a hack to avoid invoking the linker.

Maybe I should use a tool-chain file? I've never used this feature of
CMake before but perhaps that would solve these problems. That way I
could have CMake use, llvm-link rather than the system linker. Then
things wouldn't break when trying to link.

Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Obtaining header file dependencies of a source file manually

[Dan Liew]

On 30 November 2015 at 18:35, Brad King <brad.k...@kitware.com> wrote:
> On 11/30/2015 01:32 PM, Dan Liew wrote:
>> It works but only for makefile generators... That's an annoying
>> limitation. I'll file a feature request to get this implemented for
>> other generators.
>
> It happens to work for Makefile generators because it was easy to
> implement since those generators already do their own scanning.
> For other generators it is not possible to implement.

Well I found the open issue [1]. It's been open for a while.

It doesn't look completely impossible. For Ninja, it looks like it has
some support for compiler
generated dependency files [2]. Incorporating that into
``add_custom_command()`` would require
an extra call to the host compiler to generate the dependencies when
the custom command is invoked.

For other generators that are Makefile or Ninja based I guess that
approach wouldn't work.

There is an alternative which I suggested in the post. Have CMake
determine the dependencies of the files passed to ``IMPLICIT_DEPENDS``
at configure
time and spit that into the build files of the generator (that would
work for any generator). Then have any changes made to the files
passed to ``IMPLICIT_DEPENDS``
trigger a reconfigure so that the dependencies can be recomputed. For
Makefiles you can don't need to do this and can take the "fast path"
instead.

[1] https://cmake.org/Bug/view.php?id=13234
[2] https://ninja-build.org/manual.html#_depfile

Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi Michael,

> Not going into detail as I'm typing on the phone, but this really sounds
> like a case where a "SuperBuild"
> (http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html)
> can help you to simplify things a lot.

Thanks for the suggestion but this certainly is not a case where a
"SuperBuild" would help. CMake does not know how to configure a
compiler that can produce LLVM Bitcode so using a "SuperBuild" is not
going to help.

Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 18:03, Dan Liew <d...@su-root.co.uk> wrote:
> Hi,
>
> On 30 November 2015 at 08:09, Petr Kmoch <petr.km...@gmail.com> wrote:
>> Hi Dan,
>>
>> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
>> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>>
>> I don't have direct experience with it, but it looks like it could do what
>> you're looking for.
>
> Oh. That sounds exactly like what I'm looking for!

It works but only for makefile generators... That's an annoying
limitation. I'll file a feature request to get this implemented for
other generators.

Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Obtaining header file dependencies of a source file manually

[Dan Liew]

Hi,

On 30 November 2015 at 08:09, Petr Kmoch  wrote:
> Hi Dan,
>
> you could look into the IMPLICIT_DEPENDS argument of add_custom_command:
> https://cmake.org/cmake/help/latest/command/add_custom_command.html
>
> I don't have direct experience with it, but it looks like it could do what
> you're looking for.

Oh. That sounds exactly like what I'm looking for!

Thanks,
Dan.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

 foolib is defined in this CMakeLists.txt:
 https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt

 That is the (only) context in which you can extend the definition of the
 target with custom commands.

Since when? I haven't seen that documented anywhere. IMHO this
behavior is counter-intuitive, in general I expect the scope of a
target to not depend on the cmake command I am trying to use. Seeing
as targets seem to be visible globally to all the commands (that I've
used so far) it seems to reasonable to me to expect
add_custom_command() to be able to see these targets too.
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

Hi,

I'm almost certain this is a bug but I thought I'd ask the mailing lists first.

I'm observing a problem with CMake's add_custom_command() when using
the TARGET version of the signature.

Code demonstrating the issue can be found at [1]

In ``test/CMakeLists.txt`` [2] I try using add_custom_command() to
build and run an executable every time the ``foolib`` library is
rebuilt. The motivation behind doing this is to have some very quick
and simple library tests run every time the library is built.

This use of add_custom_command() does not seem to work at all.

Using CMake 2.8.12.2 the requested command is not invoked when running
``make foolib``. I am aware that the custom command won't run if
``foolib`` has already been made but even if I do a clean build the
custom command specified does not run.

When using CMake 3.2.3 I get a warning about CMP0040 which complains
that the target passed to the TARGET argument in
``add_custom_command()`` doesn't exist.

```
  Policy CMP0040 is not set: The target in the TARGET signature of
  add_custom_command() must exist.  Run cmake --help-policy CMP0040 for
  policy details.  Use the cmake_policy command to set the policy and
  suppress this warning.

  The target name foolib is unknown in this context.
This warning is for project developers.  Use -Wno-dev to suppress it
```


This doesn't make sense the target **clearly exists and is in scope**
because the ``simple_test`` executable links against it and also it is
possible to read properties of the target.

Seems like there's some sort of weird scope issue going on here.

Thoughts?

[1] https://github.com/delcypher/cmake_add_custom_command_bug
[2] 
https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/test/CMakeLists.txt

Thanks,
Dan Liew
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

   I haven't seen that documented anywhere. IMHO this
 behavior is counter-intuitive, in general I expect the scope of a
 target to not depend on the cmake command I am trying to use.


 I think it is sensible that the definition of a target is scoped to one
 single directory.
 Where the definition of a target consists of e.g. sources, properties,
 dependencies and custom commands related to the target.

 You can reference/query global targets in other directories but you can not
 change them.

It seems sensible from a safety standpoint (preventing targets from
accidentally being modified from other directories) but it also
limiting in that
it prevents certain directory layouts (like the one I tried in my example).
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Dan Liew]

For reference I've opened up a bug report
http://www.cmake.org/Bug/view.php?id=15681
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Incorrect path handling in generation of export files

[Dan Liew]

Hi,

There is a bug in CMake's export file generator where it does not
correctly escape Windows paths when generating export files . This was
originally reported on the LLVM mailing list [1]. I'm using CMake
3.2.3.

In a generated export file I see

```
# Create imported target LLVMDebugInfoPDB
add_library(LLVMDebugInfoPDB STATIC IMPORTED)

set_target_properties(LLVMDebugInfoPDB PROPERTIES
  INTERFACE_LINK_LIBRARIES LLVMObject;LLVMSupport;C:\Program Files
(x86)\Microsoft Visual Studio 14.0\DIA SDK\lib\diaguids.lib
)
```

One of the libraries listed in the INTERFACE_LINK_LIBRARIES has
invalid syntax because the slashes have not been escaped. I believe
the correct solution would be to have CMake convert all paths to CMake
style paths before writing them to export files.


Brad King (CC'ed) had this comment

```
However, CMake should also be taught to escape the backslashes correctly
when generating the export files.  Take a look at

 Source/cmExportFileGenerator.cxx
 Source/cmExportBuildFileGenerator.cxx
 Source/cmExportInstallFileGenerator.cxx

in the CMake source tree.  There are several places that just generate
double quotes around a raw value that should instead use EscapeForCMake.
```

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-June/086958.html

Thanks,
Dan
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers