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()`` whi
Hi,
On 28 March 2016 at 15:05, Brad King 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 becau
Hi,
I tried writing a add_custom_command statement that will output the
generated file into the same directory as another target
```
set(OUTPUT_NAME "$/MyThing.dll")
add_custom_command(OUTPUT "${OUTPUT_NAME}"
COMMAND "csc.exe" "/output:$" "MySource.cs"
)
```
This doesn't work. CMake emits thi
On 3 March 2016 at 22:02, Nils Gladitz 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 &q
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 th
> 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 expect
>> 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
> For other generators that are Makefile or Ninja based I guess that
> approach wouldn't work.
Sorry that should read
For other generators that **aren't** Makefile or Ninja based I guess
that approach wouldn't work.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMak
On 30 November 2015 at 18:35, Brad King 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 ha
Hi,
On 30 November 2015 at 18:03, Dan Liew wrote:
> 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_comma
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
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
Hi,
# TL;DR
I need a way of determining the header file dependencies of a source
file and inform CMake about them. CMake doesn't do this automatically
because I'm using custom commands for the compilation step so CMake
doesn't do it's usual magic of automatically inferring source file
header depe
>> 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
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
> 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. IM
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/
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
18 matches
Mail list logo
