Are you thinking of tools that are invoked instead of the compiler, like clazy-
standalone? I thought about mentioning a potential interest of my idea for using
such tools (but forgot in the end).
Yes, that and all the other tools supported by CMake as a "pre-command"
before the compiler invoca
Sylvain Joubert wrote:
> My use case is for static analysis builds. For example, my CI setup has
> multiple of them including cppcheck, clang-tidy and iwyu through the
> CMake integration. And since I'd like to keep separate builds for each
> of them this requires 3 full build whose results I don'
On 10/09/2018 02:00 PM, Rolf Eike Beer wrote:
> Seems like you missed one part of the announcement mail ;)
>
> Policies
> ==
The announcement comes from the release notes, and all policies
are mentioned there in relevant bullets. We've never called them
out separately in such notes. One can
Robert Maynard wrote:
> I am proud to announce the first CMake 3.13 release candidate.
> https://cmake.org/download/
>
> Documentation is available at:
> https://cmake.org/cmake/help/v3.13
>
> Release notes appear below and are also published at
> https://cmake.org/cmake/help/v3.13/release/
I'd also like something like that for another use case of mine which
stumble upon the same limitations (compiler checks, linking and Qt
generated content).
My use case is for static analysis builds. For example, my CI setup has
multiple of them including cppcheck, clang-tidy and iwyu through t
I am proud to announce the first CMake 3.13 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.13
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.13/release/3.13.html
Some of the more significan
I found the solution!!
I just add the plugins attached to the Qt Component (in my case Qt5Widgets) and
install it:
set(qtplugins)
foreach(plugin ${Qt5Widgets_PLUGINS})
get_target_property(_loc ${plugin} LOCATION)
list(APPEND qtplugins ${_loc})
endforeach()
install_qt5_executable("${exe}
Hi,
Apologies, longish post ahead. I've tried to present my idea and the thought
train leading up to it as succinctly as possible. Hope I at least strike a
chord!
Clang and GCC have long supported an option that makes them stop after the
syntax-verification stage: -fsyntax-only . This has the
Hello everyone,
I try to install a bundle application on macOS.
I successfully create the bundle and add all dependencies to Qt event the
plugin platform libqcocoa.dylib.
Unfortunately, when I launch the installed app, the window style is not the
same as the build app style (macOS) as you can se
Marc
Thank you. That fixes it.
JB
From: Marc CHEVRIER [marc.chevr...@gmail.com]
Sent: 09 October 2018 09:52
To: Biddiscombe, John A.
Cc: cmake@cmake.org
Subject: Re: [CMake] target_compile_flags and PUBLIC
Have a look at '$' and '$'
generator expressions.
Le ma
Hi John,
you could put those flags as PUBLIC into a separate INTERFACE target (let's
call it hpxFlags) and then do
target_libraries(hpx PRIVATE hpxFlags)
Then create another interface target hpxForTests to combine those two
targets:
target_link_libraries(hpxForTests PUBLIC hpx hpxFlags)
A
Have a look at '$' and '$'
generator expressions.
Le mar. 9 oct. 2018 à 09:48, Biddiscombe, John A. a
écrit :
> I have a problem with exported flags from a project.
>
> If I use `target_compile_options(hpx PUBLIC ${flags})` hpx is compiled
> with the flags, and all 500+ tests within the project
I have a problem with exported flags from a project.
If I use `target_compile_options(hpx PUBLIC ${flags})` hpx is compiled with the
flags, and all 500+ tests within the project that depend on hpx inherit the
flags too, so they get built correctly. However, the `HPXTargets.cmake` file
that is g
13 matches
Mail list logo
