ExternalProject does its work at build time, so too late for find_package which
is executed at config time.
Have a look at module FetchContent which does its work before config time.
Le 19 nov. 2019 à 16:13 +0100, hex , a écrit :
> I have an external CMake project that gets exported on install.
This is the expected behaviour.
As you already discovered, it is possible to control the compilation and link
steps with variables as described in
https://cmake.org/cmake/help/latest/module/CheckCXXSourceCompiles.html#module:CheckCXXSourceCompiles.
To specify, in a more clean way, link
${CMAKE_CURRENT_SOURCE_DIR}/${DICTIONARY_LINKDEF}
> DEPENDS MyLibrary ${DICTIONARY_HEADERS} ${DICTIONARY_LINKDEF}
> COMMAND_EXPAND_LISTS
> )
>
> > Le mar. 6 août 2019 à 02:56, Marc CHEVRIER a
> > écrit :
> > > Oops, I mean: $ To generate
If you want to define a list, try to use $ rather than a space to
separate the items. This way, you will get a CMake list rather than a string:
list(APPEND DICTIONARY_INCLUDES
"-I$,$-I>")
Le 5 août 2019 à 22:56 +0200, Dakeryas , a écrit :
> I am facing the exact same issue when when joining
This is a bug already identified (see
https://gitlab.kitware.com/cmake/cmake/issues/19525).
I am currently working on a fix.
Le 1 août 2019 à 11:33 +0200, sebastian.muell...@zf.com, a écrit :
> Hi all,
>
> I’ve been trying to convince Cmake 15.1 to use the python installation in my
> virtual
uck with 3.12.4 for the
> foreseeable future. Is there a way to get the equivalent behavior in older
> versions?
>
> > On Mon, Jul 22, 2019 at 1:04 AM Marc CHEVRIER
> > wrote:
> > > You can use generator expression TARGET_FILE_BASE_NAME, available with
> > >
You can use generator expression TARGET_FILE_BASE_NAME, available with version
3.15.
Le 22 juil. 2019 à 05:24 +0200, Dustyn Blasig , a écrit :
> Hi All,
>
> I am integrating a legacy Makefile with our CMake flow, and need to pass the
> name of a CMake library target to the Makefile via
Have a look at variables ‘CMAKE_*_OUTPUT_DIRECTORY’ (Like
CMAKE_ARCHIVE_OUTPUT_DIRECTORY. See
https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html) and target
properties ‘*_OUTPUT_DIRECTORY’ (Like ARCHIVE_OUTPUT_DIRECTORY. See
You are wrongly using the STRING(REPLACE …) command.
The right way to use it to avoid list conversion is to expand the list inside
quotes (to preserve list items separators):
STRING (REPLACE "../" "" SIMPLE_LIST "${SIMPLE_LIST}")
Without the quotes, all list elements are concatenated in the
The easiest way is to launch a CMD with the correct development environment
(see for example
https://docs.microsoft.com/en-us/dotnet/framework/tools/developer-command-prompt-for-vs).
Le 22 mai 2019 à 15:58 +0200, Robert Dailey , a écrit
:
> From the command line, I want to generate Ninja build
You have to use SHELL token (see documentation of add_link_options)
add_link_options ("SHELL:-s USE_WEBGL2=1" "SHELL:-s FULL_ES2=1")
Le 12 mai 2019 à 21:14 +0200, Fredrik Orderud , a écrit :
> I'm struggling to figure out how to pass "-s USE_WEBGL2=1 -s
> FULL_ES2=1" (without the quotes) as
clearly, from what shown on http://paste.opensuse.org/14067189, c++ compiler
from OpenSuse Leap is buggy.
Expected output from readelf for executable tests_1 is « Elf file type is EXEC
(Executable file) » which is not the case. Option -no-pie is not taken into
account.
This explains the
In the meantime if this POST_BUILD command calls a specific tool you can create
a no-op shell script with the same name and put its location in the PATH
variable.
Le 6 mars 2019 à 07:41 +0100, Olivier Gomez , a
écrit :
> Thank you for your suggestions.
> I think the best option is a patch but
extra source file
> compared to the static version. Or, worked until the export stage.
>
> -Lassi
>
> From: Marc CHEVRIER
> Sent: torstai 28. helmikuuta 2019 11.37
> To: cmake-developers@cmake.org; Lassi Niemistö
> Subject: Re: [cmake-developers] Mandatory export of a stati
Hi,
It is perfectly normal that CMake requires static library to be exported when
command ’target_link_libraries(fooshared barstatic)’ is specified because this
is equivalent to command 'target_link_libraries(fooshared PUBLIC barstatic)’.
As you have already discovered, using command
It is quite inexact because a target can store many information like include
directories or preprocessor definitions for example (through properties like
INCLUDE_DIRECTORIES or COMPILE_DEFINITIONS).
So it make sense to enable to specify link libraries to a static library using
PRIVATE or
I am not convince that the proposed syntax is a good idea because it introduce
a new syntax just to solve one action on a list.
What about introducing a syntax similar to the version comparison:
• LENGTH_EQUAL
• LENGTH_GREATER
• LENGTH_LOWER
• etc…
To use it:
if (my_list LENGTH_EQUAL 1)
# do
0100, Lars , a écrit :
> Marc,
>
> Appreciate the quick and helpful response.
>
> In a config file that supports multiple platforms, do I need to create
> import_location_path variable and populate it depending on platform and 32/64
> etc? Any other options?
>
> Thanks.
>
>
Properties IMPORTED_LOCATION* do not support generator expressions.
Generally speaking, if a property supports generator expression, it is
explicitly specified in documentation.
Le 21 déc. 2018 à 13:07 +0100, Lars , a écrit :
> Hello,
>
> Trying to import an external library but having some
Command target_link_libraries do not populate directly the properties of the
target due to many constraints regarding the values given to the command
(generator expressions, other targets, etc…).
The full contents is taken into account at generation time not at the
configuration time. This is
I think the discussion is shifting from the initial problem which was unwanted
warning « Command line warning D9025: overriding '/W3' with '/W4' ».
Changing defaults is not a good idea from my point of view because relying on
defaults can be problematic if Microsoft decide to change the default
Have a look at the documentation :
https://cmake.org/cmake/help/v3.13/
Le 6 déc. 2018 à 09:51 +0100, Andy , a écrit :
> In cmake I have:
> if (${CMAKE_BUILD_TYPE} STREQUAL Release)
> message(WARNING "Release")
> endif()
>
> if (${CMAKE_BUILD_TYPE} STREQUAL Debug)
> message(WARNING "Debug")
>
)
>> set_target_properties( python PROPERTIES IMPORTED_LOCATION /usr/lib32/
>> libpython2.6.so )
>> target_include_directories(python SYSTEM ...
>>
>
> I think you can do that but it replaces the use of find_package(Python2
> COMPONENTS Development)
> may be
The way you proceed is wrong.
The system configuration is determined during the 'project' function call.
Setting information after this call is useless. So, in your example, on a
64bit system, the compilation configuration will be 64bit (variable
CMAKE_SIZEOF_VOID_P has value 8).
This explain why
Variable must be specified using upper case. So 'set (JAVA_HOME ...)'
should be OK (or environment variable JAVA_HOME is OK as well). javac is
expected to be in $JAVA_HOME/bin.
Le lun. 22 oct. 2018 à 10:16, Stéphane Ancelot a
écrit :
> Hi,
>
> If I set java_home in cmake 3.12 ,
Option INCLUDE_JARS is used to specify classpath javac option for java
sources compilation.
Currently, there is no possibility to add jars using add_jar command. You
have to use a custom command for that purpose.
Le lun. 22 oct. 2018 à 11:05, Stéphane Ancelot a
écrit :
> Hi,
>
> I have to
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
arch?q=optimized.lib+cmake
>
>
>
> Regards,
>
> Björn
>
>
>
>
>
> *From:* Marc CHEVRIER
> *Sent:* Thursday, October 4, 2018 6:59 PM
> *To:* Björn Blissing
> *Cc:* Andrew Fuller ; Eric Noulard <
> eric.noul...@gmail.com>; CMake Mailinglist
>
>
I am afraid that you cannot mix "optimized" or "debug" keywords with
"generator expressions" because keywords handling is done during evaluation
of command "target_link_libraries" and "generator expressions" are
evaluated during generation.
And target_link_libraries expect following pattern: []
Using a cache variable seems not required. A function creates a new scope
and inherit a copy of all variables defined in the upper scope.
So, by adding a set command using PARENT_SCOPE in your function you can
update the variable in the parent scope:
function(addTest targetName)
LINK_FLAGS does not support expressions.
However, property LINK_OPTIONS (and INTERFACE counterpart) support
generator expressions. These properties are new for version 3.13 which will
be available soon (probably next month).
Le mer. 26 sept. 2018 à 05:21, Hendrik Greving <
)
add_subdirectory("my_dir")
and in "my_dir":
add_test(TEST1 ...)
set_property(TEST TEST1 APPEND PROPERTY LABELS ${MY_LABELS})
Le mer. 19 sept. 2018 à 19:45, Raffi Enficiaud <
raffi.enfici...@mines-paris.org> a écrit :
> On 19.09.18 08:25, Marc CHEVRIER wrote:
> >
directory property 'TESTS' returns the tests created in the *current* directory
only.
The main reason to this limitation is the fact that tests created in
different directories can have same name.
Le mer. 19 sept. 2018 à 02:22, Raffi Enficiaud <
raffi.enfici...@mines-paris.org> a écrit :
> Hi,
seeing a property (from the first link you sent) that would allow me to do
> that.
>
>
>
> --
>
> Michael Jackson | Owner, President
>
> BlueQuartz Software
>
> [e] mike.jack...@bluequartz.net
>
> [w] www.bluequartz.net
>
>
>
> *From: *
The best approach is to use properties (see
https://cmake.org/cmake/help/git-master/manual/cmake-properties.7.html).
At directory level and target level you can use property
'COMPILE_OPTIONS'. These properties can be updated using, respectively
'add_compile_options' and 'target_compile_options'.
Hi,
To avoid this, put link flags in ‘LINK_FLAGS’ target properly.
´target_link_libraries’ is populating ´LINK_LIBRARIES’ target property.
Le sam. 8 sept. 2018 à 01:40, Alvin Chu a écrit :
> Hi cmake team,
> I'm using cmake 3.12.1, and building a project which has cuda codes, the
> cmake file
'define_property' is nearly useless except for documentation.
Export of custom properties is managed through target property
'EXPORT_PROPERTIES'.
Le mer. 22 août 2018 à 15:58, Raphael Grimm a
écrit :
> Hi,
>
> I added a custom target property via 'define_property'
>
ises many more issues as
> I need my project to be able to build with many different versions of the
> Intel compiler.
>
>
>
> Thanks in advance,
>
>
>
>- Tom
>
>
>
>
>
> *From: *Marc CHEVRIER
> *Date: *Saturday, July 7, 2018 at 1:49 AM
> *
May be using a toolchain file is more appropriate. See
https://cmake.org/cmake/help/v3.12/manual/cmake-toolchains.7.html
Le ven. 6 juil. 2018 à 22:59, Clune, Thomas L. (GSFC-6101) <
thomas.l.cl...@nasa.gov> a écrit :
> To use the Intel compiler, one must use an environment variable that
>
Next version of CMake (3.13) will supports properties LINK_OPTIONS as well
as INTERFACE_LINK_OPTIONS.
Le mer. 4 juil. 2018 à 16:02, Francis Giraldeau
a écrit :
> > However, it seems no property exists to actually specify the library dir
> > of imported target, nor the linker flags to pass when
You can use a new target, built by all, depending on your initial target:
add_custom_target(build_blah_X ALL)
add_dependencies(build_blah_X blah_X)
Le mer. 4 juil. 2018 à 03:33, Andrew White a
écrit :
> How do I add an excluded (executable) target to the build. I know that if
> I add a
LINK_FLAGS property do not support generator expressions.
In CMake 3.13, directory and target properties LINK_OPTIONS, supporting
generator expressions, managed by commands add_link_options and
target_link_options are introduced, .
For earlier versions you can use global variables to set flags
FYI, next release (3.13) will relaxing this contraint so you will be able
to apply this strategy.
Le mar. 3 juil. 2018 à 08:05, Andrew White a
écrit :
> We have a number of projects that include other projects. Some of the
> parent projects are cross-compile projects with various odd
FYI: Starting with CMake 3.11, it is now possible to define an alias of an
imported target.
Le lun. 2 juil. 2018 à 09:27, Petr Kmoch a écrit :
> Hi Bram.
>
> Wild idea: could you also define a non-namespaced target `foo` and craft
> it such that linking against it generates a linker warning?
e
> BUILD_INTERFACE generator expression and line breaks / list items?
> It seems to work fine in target_sources when enclosing multiple
> lines/files, but in target_include_directories I need one
> BUILD_INTERFACE expression per directory or I get an error.
>
> Thanks again,
>
> Ric
You can manage different paths (one for build export and one for install
export) by using '$' and '$'.
'$' accepts absolute paths and
'$ expects paths relative to the install prefix
(CMAKE_INSTALL_PREFIX variable).
.
Le lun. 25 juin 2018 à 16:23, Rich T a écrit :
> Hi everyone, I've a question
There is no specific reason.
But, starting with CMake 3.12, a new approach to manage python is available
(modules FindPython2, FindPython3 and FindPython) which take care of
consistency between interpreter and libraries and rely, when possible, on
python-config tool.
Le ven. 22 juin 2018 à
Starting with CMake v3.11, it is now possible to aliasing an imported
target. So you can have something like that:
if (BUILD_MY_LIB)
add_library(my_lib SHARED )
add_library(MY_NAMESPACE::mylib ALIAS my_lib)
else()
add_library(system_lib SHARED IMPORTED GLOBAL)
set_property(TARGET
functions, you can easily ensure to use always the
correct compiler for each build environment.
Le mer. 6 juin 2018 à 16:50, René J. V. Bertin a
écrit :
> Marc CHEVRIER wrote:
>
> > You can easily avoid this bad experience by using different builds
> > environments : one per compile
Le dim. 3 juin 2018 à 18:40, Hendrik Sattler a
écrit :
>
>
> Am 3. Juni 2018 16:33:12 MESZ schrieb Marc CHEVRIER <
> marc.chevr...@gmail.com>:
> >In fact, the right way to manage « composite » options is to use «
> >SHELL: »
> >prefix (introduced in up-com
> realloc_lhs>")
>
> you get a single quoted token "-assume realloc_lhs" on the compile line
> which the compiler doesn't understand. The correct thing is
>
>
> GOOD:
> add_compile_options("$<$:-assume;realloc_lhs>")
>
>
> On Sun, Ju
) and that worked too. Thanks all!
>
> On Sun, Jun 3, 2018 at 12:18 AM Marc CHEVRIER
> wrote:
>
>> Did you try with $ rather than the ; character?
>>
>> Le dim. 3 juin 2018 à 06:24, Craig Scott a
>> écrit :
>>
>>> On Sun, Jun 3, 2018 at 12:34
Did you try with $ rather than the ; character?
Le dim. 3 juin 2018 à 06:24, Craig Scott a écrit :
> On Sun, Jun 3, 2018 at 12:34 PM, Neil Carlson
> wrote:
>
>> On Sat, Jun 2, 2018 at 4:53 PM Stephen McDowell
>> wrote:
>>
>>> It should be a CMake list, which is delineated by semicolons.
>>>
You can easily avoid this bad experience by using different builds
environments : one per compiler !
Le sam. 2 juin 2018 à 11:43, René J.V. Bertin a
écrit :
> Hi,
>
> This happened once too often for me: I apply successive tweaks to a
> CMakeCache file, reinvoke make (or ninja) and then at some
54 matches
Mail list logo
