On 04.07.2018 21:21, Oleh Kravchenko wrote:
In my case I can't use target for this.
You mean you can't use a proxy target? Why?
There are any hard limits which block fixing of this behaviour?
Perhaps CMake could do implicitly what you now have to do explicitly but
I haven't really thought
Hi Nils,
Thank you for your answer!
In my case I can't use target for this.
There are any hard limits which block fixing of this behaviour?
By the way, can I have two and more targets in one build directory?
04.07.18 20:19, Nils Gladitz пише:
> On 04.07.2018 18:52, Oleh Kravchenko wrote:
>
>> H
On 04.07.2018 18:52, Oleh Kravchenko wrote:
Hello CMake Developers!
Looks like I found interesting bug in CMake:
- ADD_CUSTOM_TARGET() always creates Makefile rule for ADD_CUSTOM_COMMAND().
- As result build simetimes failed if specified -jN for make.
FWIW this is documented behavior (so not
Hello everyone,
I've been thinking about designing a new syntax for CMake that better
expresses some of the functionality that I've seen in modern CMake code.
I've started a CMake parsing library and plan on using it to design the new
syntax while maintaining support for the traditional syntax as
Hello CMake Developers!
Looks like I found interesting bug in CMake:
- ADD_CUSTOM_TARGET() always creates Makefile rule for ADD_CUSTOM_COMMAND().
- As result build simetimes failed if specified -jN for make.
Please find attached simple project which reproduce the problem.
> [ 12%] Generate /home
Hi,
I think I may have found a problem related to CMake’s handling of
-Wl,-rpath-link on Linux in combination with cross-compiling against a sysroot.
You can grab a minimal example that exposes the behavior at
https://github.com/neverpanic/cmake-rpath-link-example.
The example uses a chain of