Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

On 11/8/19 5:17 AM, Alexander wrote: > /DEF:"E:/workspace/cmake_test_option/tesseract/bin/libtesseract.dir/Release/exports.def" > is added by CMake automatically and I cannot control it (CMake first creates > a file > objects.txt and then exports.def from it). That behavior is not default, but

Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

On 11/5/19 7:30 AM, Alexander wrote: > string(APPEND CMAKE_SHARED_LINKER_FLAGS " -DEF:\"foo_1.def\" > -DEF111:\"foo_1.def\"") This was the first you've mentioned using more than one copy of the flag. I tested with this: ``` string(APPEND CMAKE_SHARED_LINKER_FLAGS "

Re: [cmake-developers] These two generator expressions should be equivalent, but one working while the other not working. Bug?

On 10/24/19 12:18 AM, Alan W. Irwin wrote: > $ > >Expression did not evaluate to a known generator expression The `*_COMPILER_ID` generator expressions are a hard-coded set corresponding to the languages supported by upstream CMake: * C_COMPILER_ID * CXX_COMPILER_ID * CUDA_COMPILER_ID

Re: [cmake-developers] CTest load balancing

On 10/16/19 10:05 AM, Wouter Klouwen wrote: > Is the intent for CTest to specifically manage CPU load or system load > overall? I don't think a careful distinction was made at the time. If Linux needs some updates to be consistent with other platforms then that would be fine with me. -Brad --

Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

On 10/9/19 6:04 PM, Alexander wrote: > it deliberately ignores /DEF: which makes impossible to add /DEF: this easy > (and for me preferable) way. The code ``` string(APPEND CMAKE_SHARED_LINKER_FLAGS " -DEF:\"${CMAKE_CURRENT_SOURCE_DIR}/foo.def\"") ``` works fine for me. So does this: ```

Re: [cmake-developers] CMake removes /DEF: option in CMAKE_SHARED_LINKER_FLAGS

On 10/8/19 8:10 AM, Alexander wrote: > I found that CMake ignores /DEF: option in CMAKE_SHARED_LINKER_FLAGS. > I would like to know if this is an expected behaviour or a bug. A module definition file can be passed as a normal source file and CMake will automatically add `/DEF:...` to the link

Re: [cmake-developers] Revitalize --find-package mode?

On 10/2/19 9:24 AM, Nagy-Egri Máté Ferenc via cmake-developers wrote: > to obtain dependency information is no longer maintained in CMake, > or at least discouraged for new projects. For reference, the `cmake --find-package` mode documentation you mentioned is here: *

Re: [cmake-developers] Possible feature request concerning conditional linking support by generator expressions

On 9/24/19 5:02 PM, Alan W. Irwin wrote: > I. Possible feature request > > After reading through the generator-expression documentation at > > it appears for my use case (see below) I need generator expressions of >

Re: [cmake-developers] EXCLUDE_FROM_ALL behavior change

On 9/24/19 8:12 AM, Charles Huet wrote: > in CMake 3.14 the EXCLUDE_FROM_ALL option of add_subdirectory had a behavior > change. > We are negatively impacted by this change, as we are in the same exact > scenario as > this user: https://cmake.org/pipermail/cmake/2019-September/069978.html

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

On 9/13/19 1:30 PM, Tushar Maheshwari wrote: > Thanks for the quick response. > I have my commits separated by file groups. I'll open small MRs > collecting the related groups. Thanks. Please just keep a couple MRs open at a time so we don't overwhelm the CI builders. After some are merged you

Re: [cmake-developers] Proposal: Using smart pointers to own dynamically allocated memory

On 9/13/19 12:58 PM, Kyle Edwards via cmake-developers wrote: > On Fri, 2019-09-13 at 22:08 +0530, Tushar Maheshwari wrote: >> I have pushed some sample commits to >> https://gitlab.kitware.com/tusharpm/cmake/commits/smart_mem. >> >> If this is something I can pursue, I would appreciate a review

Re: [cmake-developers] escape double quote in generated file

On 8/30/19 10:36 AM, Eugene Karpov wrote: > use it later for precompiled header generation. FYI, CMake 3.16 will have first-class support for PCH: https://gitlab.kitware.com/cmake/cmake/merge_requests/3553 -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the

Re: [cmake-developers] cmake-file-api and CTest

On 8/22/19 2:41 PM, David Cole via cmake-developers wrote: > The return code indicates a stack overflow. Let's hope it is not intended. Thanks folks. I opened an issue for that here: * https://gitlab.kitware.com/cmake/cmake/issues/19629 -Brad -- Powered by www.kitware.com Please keep

Re: [cmake-developers] ncurses sub-dir and include path

On 8/1/19 6:35 PM, Christoph Grüninger wrote: >> Why is that wrong? As you said it has both `ncurses.h` and `curses.h`. >> Even though they are symlinks one can still use them to compile. > > CMake includes form.h, not (n)curses.h. So form.h is later not found, > because after finding

Re: [cmake-developers] ncurses sub-dir and include path

On 7/30/19 4:57 PM, Christoph Grüninger wrote: > I always end up with /usr/include/ being the CURSES_INCLUDE_PATH. Why is that wrong? As you said it has both `ncurses.h` and `curses.h`. Even though they are symlinks one can still use them to compile. To ignore the symlinks one could configure

Re: [cmake-developers] ncurses sub-dir and include path

On 7/28/19 4:21 PM, Christoph Grüninger wrote: > -include_directories(${CURSES_INCLUDE_PATH}) > +include_directories(${CURSES_INCLUDE_PATH}/ncurses/) Why is that needed given the conditions here: https://gitlab.kitware.com/cmake/cmake/blob/v3.15.1/Source/CursesDialog/form/form.h#L38-57

Re: [cmake-developers] ninja generator does NOT use absolute paths at rules?

On 7/22/19 4:47 PM, Claus Klein wrote: > Than I realized , the ninja.rules files contains NO absolute paths > to target source and header files. Historically the Ninja ecosystem encourages use of relative paths. There is an issue for this in CMake:

Re: [cmake-developers] cmake-file-api and CTest

On 7/7/19 5:04 AM, Nagy-Egri Máté Ferenc via cmake-developers wrote: > I am trying to cook a CTest back-end to the Test Explorer UI extension > for VS Code as a summer project and I thought of using the new cmake-file-api > for it. CTest's model of the test suite is distinct from CMake's model

Re: [cmake-developers] target_link_libraries links mathlib as -lm rather than /libm.so, why?

On 6/17/19 11:22 PM, Alan W. Irwin wrote: > target_link_libraries( /usr/lib/x86_64-linux-gnu/libm.so) > > results in an actual link option "-lm". Thanks. I can reproduce that and have opened an issue with an explanation: https://gitlab.kitware.com/cmake/cmake/issues/19399 It occurs

Re: [cmake-developers] No more emails from gitlab.kitware.com

On 4/15/19 3:56 AM, Sebastian Holtermann wrote: > after changing my account (@sebholt) password in gitlab.kitware.com, I > don't get any emails from it anymore. Login and everything web based > works, but no emails. Did something change there? Verify that your email address is still as

Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy

On 3/29/19 8:51 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > - pushing to kitware without 2FA fails > - pushing to kitware with 2FA fails Try using gitlab's own deployment on "gitlab.com". If that works then we can investigate differences. -Brad -- Powered by www.kitware.com Please keep

Re: [cmake-developers] Source code ///! comments

On 3/26/19 8:28 AM, Sebastian Holtermann wrote: > Looking through the source code I found various comments > starting with "///!" > If Doxygen is targeted, the comment should start with either "///" or > "//!". It's likely a typo. For reference, I personally prefer `/** */`. -Brad -- Powered

Re: [cmake-developers] Trojan in latest release

On 3/22/19 9:56 AM, Brad King wrote: > > https://github.com/Kitware/CMake/releases/download/v3.14.0/cmake-3.14.0-win64-x64.zip > > and uploaded just `bin/cmake.exe` to virustotal.com: it does claim > that `Trojan:Win32/Skeeyah.I` appears: > > This is almost certainly a

Re: [cmake-developers] Trojan in latest release

On 3/21/19 12:21 PM, Cristian Adam wrote: > Also worth mentioning that Virustotal has nothing on both 32 and 64 bit files: I extracted https://github.com/Kitware/CMake/releases/download/v3.14.0/cmake-3.14.0-win64-x64.zip and uploaded just `bin/cmake.exe` to virustotal.com: it does claim that

Re: [cmake-developers] cmake server to cmake file api swicth

On 3/21/19 2:19 PM, Eric Noulard wrote: > Can any CMake developer that has been participating in this new > file api shed some light on the rational of this foreseen switch? > I'm just curious about it. What was wrong/problematic with server mode? > Does the new file api solves some IDE

Re: [cmake-developers] Trojan in latest release

On 3/21/19 2:01 PM, kevin wrote: > I have not actually seen the file, because windows defender is > preventing the download from completing. I just tried using MS Edge on an up-to-date Win 10 Pro with Windows Defender enabled. It is able to download and scan the file, and finds nothing. -Brad

Re: [cmake-developers] Trojan in latest release

On 3/21/19 12:31 PM, kevin wrote: > Linked from https://camel.org/download I'll assume you meant `cmake.org` there. > Platform->windows win64-x64 installer: ... That would be https://github.com/Kitware/CMake/releases/download/v3.14.0/cmake-3.14.0-win64-x64.msi I downloaded it and got a

Re: [cmake-developers] signing Windows binaries

On 3/21/19 12:21 PM, Cristian Adam wrote: > I think it would be great if Kitware would buy an authenticode > certificate to sign the Windows builds. Is there a bug report on this? I don't recall if there is an open issue but we are aware that the Windows binaries could be signed and are not. We

Re: [cmake-developers] Trojan in latest release

On 3/21/19 12:05 PM, kevin wrote: > I just tried to install the latest release and noticed it contained Skeeyah.l What is the URL of the binary you downloaded? What is the sha256 sum of the installer file on your local disk? -Brad -- Powered by www.kitware.com Please keep messages on-topic

Re: [cmake-developers] [CDT] Improving CDT4 generator

On 3/20/19 5:20 PM, Alexander Neundorf wrote: > On 2019 M03 20, Wed 13:53:49 CET Brad King wrote: >> CMake's new file-api: >> >> https://cmake.org/cmake/help/v3.14/manual/cmake-file-api.7.html >> >> That is now the intended way for third-party IDEs to display CM

Re: [cmake-developers] execute_process: how to detect TIMEOUT

On 3/20/19 11:53 AM, Joachim Wuttke wrote: > The command execute_process has an option TIMEOUT. > This option would be even more useful if one > would notice when a timeout happened. > Is there a way to tell from any of the outcome > variables whether the process ran into timeout? The

Re: [cmake-developers] [CDT] Improving CDT4 generator

On 3/19/19 4:57 PM, David wrote: > since Eclipse 9.2 (or 9.1 do not remember), the CMake CDT4 Generator > does not work as expected for C++ Project. > > What is the best way to propose an update ? Please see contribution instructions here:

Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1

On 3/19/19 11:57 AM, Rolf Eike Beer wrote: > It has nothing to do with either the policies or the order of > cmake_minimum_required() and project(). Okay. My order comment was a side note and should be corrected either way. > If I require version 3.0 it works, with 3.1 it fails. See this code

Re: [cmake-developers] Pushing to gitlab.kitware.org from behind a ssl proxy

On 3/19/19 2:21 AM, Stuermer, Michael SP/HZA-ZSEP wrote: > remote: HTTP Basic: Access denied > fatal: Authentication failed for > 'https://gitlab.kitware.com//cmake.git/' Try creating a personal access token to use during auth instead: *

Re: [cmake-developers] different behavior of cmake_minimum_required(3.0) and 3.1

On 3/15/19 6:10 PM, Rolf Eike Beer wrote: > I suspected it was a policy thing, so I tried this: > > foreach(_p RANGE 21 54) >cmake_policy(SET CMP00${_p} OLD) > endforeach() Only policies 51-54 were added between 3.0 and 3.1. I suggest testing with cmake_minimum_required(VERSION

Re: [cmake-developers] Exporting an imported target not supported?

On 3/12/19 9:55 AM, Lassi Niemistö wrote: > is there a technical reason why it would not be a good idea to > allow exporting the imported targets with all their properties? We have not thought deeply through the semantics of that in general. One of the main challenges is relocation handling.

Re: [cmake-developers] Exporting an imported target not supported?

On 3/12/19 6:57 AM, Lassi Niemistö wrote: > What to do in order to get rid of the extlib_interface workaround? > I have not yet seen any means of "exporting" the properties of an > imported target to tree2. The file `cmake_test_system_lassi/tree1/Tree1Config.cmake` should have code to re-create

Re: [cmake-developers] Exporting an imported target not supported?

On 3/11/19 8:50 AM, Lassi Niemistö wrote: > I cannot see any automatic rpath-link generation if I try the above. Should I? Please post a minimal example tarball showing your case in practice. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] Exporting an imported target not supported?

On 3/8/19 1:11 AM, Lassi Niemistö wrote: > Am I just missing something and should be able to install the export > of “extlib” without installing the target itself? Any reasoning why > imported targets should not be possible to export? Any other solution > ideas for passing the custom link dir of

Re: [cmake-developers] Properly Documenting a CMake Module

On 2/12/19 6:37 PM, Timothy Wrona wrote: > a way to document custom CMake modules so that they work with the > "cmake --help-module " command There is no way to do this. The only reason --help-module exists at all is because prior to 3.0 the documentation was generated by the CMake binary itself,

Re: [cmake-developers] [PATCH] Help: Fix elseif/endif contradictions

On 2/11/19 2:06 PM, Juuso Linda Lapinlampi via cmake-developers wrote: > -Per legacy, the :command:`else` and :command:`elseif` commands admit > +Per legacy, the :command:`else` and :command:`endif` commands admit Thanks, applied here: https://gitlab.kitware.com/cmake/cmake/merge_requests/2950

Re: [cmake-developers] Shared library under Windows and CMake: DLL not found before installation

On 2/6/19 2:40 PM, Joachim Wuttke wrote: > And combine it with > > ``` > link_directories(BEFORE ${PROJECT_BINARY_DIR}/bin) > ``` > > so that tests find the libraries? No. CMAKE_RUNTIME_OUTPUT_DIRECTORY only affects the locations of the .dll files, not .a/.so/.lib. Also CMake already knows

Re: [cmake-developers] Shared library under Windows and CMake: DLL not found before installation

On 2/6/19 1:46 PM, Joachim Wuttke wrote: > What is the minimally invasive adjustment > to make the above build steps work under Windows? Windows has no RPATH to help executables locate their shared libraries. The simplest solution is to put the .exe and .dll files in the same directory (which

Re: [cmake-developers] CMake "find_package" command on a package that is not installed is unexpectedly successful

On 2/5/19 2:37 PM, Timothy Wrona wrote: > Can anyone explain to me how "find_package" is able to find the Eigen > libraries > even though they are just pasted into some arbitrary location that I never > told > the example project about? Eigen uses the CMake package registry feature:

Re: [cmake-developers] CMAKE_HOME_DIRECTORY vs CMAKE_SOURCE_DIR

On 1/29/19 5:37 AM, Joachim Wuttke wrote: > how do these two relate to each other? Their value is the same, but CMAKE_SOURCE_DIR is a normal CMake variable intended for use by projects. CMAKE_HOME_DIRECTORY is an internal cache entry used to locate the source directory when loading a

Re: [cmake-developers] $LIST_LENGTH{} syntax

On 1/22/19 1:31 PM, tors...@robitzki.de wrote: > Currently, the Code that evaluates the ${}-Syntax only evaluates the key > > const char* cmCommandArgumentParserHelper::ExpandSpecialVariable( That's the pre-CMP0053 impl. See cmMakefile::ExpandVariablesInStringNew for the modern impl. Only with

Re: [cmake-developers] $LIST_LENGTH{} syntax

On 1/22/19 10:55 AM, Marc CHEVRIER wrote: > 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 my stuff > endif() That's where this thread started.

Re: [cmake-developers] real functions (was: $LIST_LENGTH{} syntax)

On 1/22/19 10:28 AM, tors...@robitzki.de wrote: > With `$CACHE{VAR}` and `$ENV{VAR}` we already have the syntax for calling a > „function“. No, there is no obvious way to pass arguments, handle nested quoting, etc. The language was not designed for that. That is a big can of worms I'd rather

Re: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?)

On 1/22/19 7:40 AM, Daniel Franke wrote: > Whats about a Syntax like > > ${list::LENGTH} That would require dispatch after matching `${VAR}` syntax, and that lookup is one of the hottest paths according to profiling. We already have $ENV{} and $CACHE{} syntax. -Brad -- Powered by

Re: [cmake-developers] $LIST_LENGTH{} syntax (was: Support for list length expression in if()-command?)

On 1/22/19 7:09 AM, tors...@robitzki.de wrote: >> Am 22.01.2019 um 12:42 schrieb Brad King: >> Rather than a special `if` syntax, perhaps we could introduce an >> explicit `$LIST_LENGTH{mylist}` syntax. One would need to experiment >> to see if modifying the variable

Re: [cmake-developers] Support for list length expression in if()-command?

On 1/22/19 3:08 AM, tors...@robitzki.de wrote: > three use cases: > > - Checking for empty lists (I’ve showed him that this can be done > by a string compare). > - Checking for lists having more than 1 entry > - Checking for equal size of two lists. For example, if you want > to pass pairs or

Re: [cmake-developers] Support for list length expression in if()-command?

On 1/14/19 4:21 AM, Torsten Robitzki wrote: > if (LENGTH list GREATER 1) An investigation will be needed to determine whether a policy is needed to add this to the if() command to avoid possible behavior changes for existing callers. For reference, you asked this previously:

Re: [cmake-developers] BISON_TARGET doesn't use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY

On 1/8/19 6:44 AM, Brad King wrote: > On 12/25/18 1:17 AM, Mingjie Xing wrote: >> The BISON_TARGET will run bison command in CMAKE_CURRENT_SOURCE_DIR. >> >> So I just wonder whither it is better for BISON_TARGET to use >> CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY. &

Re: [cmake-developers] BISON_TARGET doesn't use CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY

On 12/25/18 1:17 AM, Mingjie Xing wrote: > The BISON_TARGET will run bison command in CMAKE_CURRENT_SOURCE_DIR. > > So I just wonder whither it is better for BISON_TARGET to use > CMAKE_CURRENT_BINARY_DIR as WORKING_DIRECTORY. Unfortunately this went unnoticed for years after the module was

Re: [cmake-developers] Test for list size

On 12/12/18 7:01 AM, Torsten Robitzki wrote: > we have often the need to test for a minimum list size > > list(LENGTH list list_size) > if (list_size GREATER 1) > > This happens so much I've almost never needed to test the length of a list. What are you trying to do? -Brad -- Powered by

Re: [cmake-developers] Slowdown of nightly builds

On 12/12/18 7:15 AM, Rolf Eike Beer wrote: > I noticed that for a few weeks the builds on my machines now take much longer > to complete, without any particular change in my setup. > The change in the dashboard can be seen on the dashboard between > 2018-11-09 and 2018-11-10. Thanks! I had

Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

On 12/9/18 8:09 AM, Marc CHEVRIER wrote: > The real question is how to manage cleanly target specific flags > overriding global or directory defaults? All the optimization and warning flags currently handled by `CMAKE__FLAGS[_]` need to have abstractions introduced (e.g. target properties or

Re: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests

On 12/5/18 5:01 PM, Alan W. Irwin wrote: > But I still don't understand exactly how ctest is run from cmake. Assuming > the > "test" target (which I have never tried) runs the "all" target and then ctest, > I guess > > cmake --build . --config Debug --target test > > would run ctest indirectly

Re: [cmake-developers] A dashboard that reveals a ctest issue on Windows when there are no tests

On 12/4/18 4:08 PM, Alan W. Irwin wrote: > Build Warnings (1) > > *** WARNING non-zero return value in ctest from: > C:\cmake-3.13.1-win64-x64\bin\cmake.exe That's in the "Build" section and indicates that the build command exited with non-zero status. If you want to try to reproduce that by

Re: [cmake-developers] [CMake] building host tools during cross compiliations (was: dependencies of cross compiliations)

On 11/27/18 5:28 AM, Rolf Eike Beer wrote: > Then I came up with: > >add_host_build("relative source dir" "build dir" [VARS]) > > This would create an entirely new CMake scope (with it's own > CMakeCache.txt and the like) in "${CMAKE_CURRENT_BUILD_DIR}/build dir", > and would not take the

Re: [cmake-developers] ENV{SOURCE_DATE_EPOCH}

On 11/20/18 4:13 PM, Oleh Kravchenko wrote: > I don't like idea to cover "cmake && make" with special bash script, > just to export SOURCE_DATE_EPOCH. SOURCE_DATE_EPOCH was created for use by packagers where tools already wrap the build. By making it an environment variable packagers could jump

Re: [cmake-developers] ENV{SOURCE_DATE_EPOCH}

On 11/20/18 10:51 AM, Oleh Kravchenko wrote: > CMake should pass this variable to build tool (GNU Make, Ninja, ...). CMake doesn't invoke the build tool to build the project. The workflow is "run cmake, then run make". With the Makefile and Ninja generators it is up to the user to provide the

Re: [cmake-developers] option to prevent in-source builds

On 11/09/2018 07:28 AM, Taylor Holberton wrote: > A lot of projects that use CMake already have a `./cmake` directory, > I would think `./cmake/init.json` would fit nicer as opposed to the > hidden directory. We could have a list of supported places so projects can choose. > I would prefer an

Re: [cmake-developers] option to prevent in-source builds

On 11/09/2018 05:34 AM, Joachim Wuttke wrote: > include(PreventInSourceBuilds) > > to protect users (and myself) from unintentionally running CMake > in the source directory. > > Would you consider adding this little module to the CMake code base? If we are going to offer an upstream solution

Re: [cmake-developers] CMake, Ninja and Clang on windows?

On 11/06/2018 05:57 AM, Tobias Hunger wrote: > we are currently trying to support Clang (without the -cl;-) on > Windows. This fails since CMake adds extra compiler flags to the > command line which are not in the expected format. Clang with a GNU-like command targeting the MSVC ABI is not

Re: [cmake-developers] KWSys build warnings on the "merlin" platform

On 10/23/2018 06:37 PM, Alan W. Irwin wrote: > look at those build warnings which > repeatedly show up on the "merlin" report for the the KWSys dashboard The warnings come from code generated by CMake. You're driving the builds with CMake 3.7 which still generated code on which gcc 8 warns.

Re: [cmake-developers] cmake checkfortran fails with Flang

On 10/22/2018 07:45 PM, blubee blubeeme wrote: > There's a newly open sourced fortran compiler flang:  > https://github.com/flang-compiler/flang > >     /usr/local/bin/flang -cpp    -E testFortranCompiler.f ... > > the fortran compiler does work if you remove the -E flag from the the >

Re: [cmake-developers] Python bindings for CTest

On 10/19/2018 11:16 AM, Jonathan R. Madsen wrote: > I just include header files and link to y'all's library like one > does with any other API.  As a matter of policy we do not offer any stable API, SDK, headers, or libraries to be linked for exposing CMake internals. Any external package that

Re: [cmake-developers] Python bindings for CTest

On 10/18/2018 11:22 PM, Jonathan R. Madsen wrote: > I have created some Python bindings for CTest. The goal was to > create an easy way for Python projects that I work with to be able > to wrap their Python compilation log (if there was one), dynamically > generate CTests and/or wrap their

Re: [cmake-developers] Generalized verbose option for cmake --build.

On 10/18/2018 11:48 AM, Ray Donnelly wrote: > Why do I need to know the necessary verbose flag to make each back-end > that cmake --build calls emit more information? If forces my build > script to switch on the platform in a really ugly way for something > I'd consider a very important feature

Re: [cmake-developers] [ANNOUNCE] CMake 3.13.0-rc1 is ready for testing

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

Re: [cmake-developers] FindLua.cmake module does not find a locally built lua library

On 09/24/2018 01:05 PM, Alan W. Irwin wrote: >> On 09/22/2018 07:09 PM, Alan W. Irwin wrote: >>> 2. Use the NAMES_PER_DIR option in the find_library command. >> This is the correct fix. >> > I agree. Please see https://gitlab.kitware.com/cmake/cmake/merge_requests/2412 -Brad -- Powered by

Re: [cmake-developers] FindLua.cmake module does not find a locally built lua library

On 09/22/2018 07:09 PM, Alan W. Irwin wrote: > 2. Use the NAMES_PER_DIR option in the find_library command. This is the correct fix. The versioned names need to go first to try to match the headers. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at:

Re: [cmake-developers] Today's PLplot contract has failed with missing Linux default .so suffix on modules

On 09/18/2018 06:07 PM, Alan W. Irwin wrote: > Just in case this has been fixed already where should I check for > obvious CMake fix activity before reporting such issues? Thanks. That failed yesterday too but it slipped by because there were many other failures to sort through while selecting a

Re: [cmake-developers] Automatically set policies for shipped modules

On 09/17/2018 09:14 AM, Craig Scott wrote: > We may also need to be careful about CMP0011 The policy scope added for our own modules can be marked as a "weak" scope. This means that specific policies can be set when the scope is first opened in C++ code, but policy settings inside the scope will

Re: [cmake-developers] Automatically set policies for shipped modules

On 09/17/2018 04:01 AM, Rolf Eike Beer wrote: > I suggest that every module included from the CMake installation is > considered clean for whatever we do and automatically gets a policy > scope push/pop right from the C++ level. That's fine with me for policies like CMP0057 that affect the

Re: [cmake-developers] Build warnings for CMake 3.12.2

On 09/08/2018 04:26 PM, Alan W. Irwin wrote: > For g++ version 8.0.2 from Debian Buster, I > recently noticed the following (bootstrap) build warnings for CMake-3.12.2: > > /home/software/cmake/cmake.git/Source/CursesDialog/cmCursesLongMessageForm.cxx:50:10: > warning: ‘char* strncpy(char*,

Re: [cmake-developers] The "cmake_host_system_information" Command

On 09/01/2018 08:50 PM, Taylor Holberton wrote: > create non-trivial variables that make queries when they are expanded I understand the proposal but I don't think we should do that. The variable expansion logic is already one of the hottest parts of the code shown in profiling. Adding dispatch

Re: [cmake-developers] OpenCL language support (was: Compiler dependencies with Unix Makefiles)

On 08/25/2018 02:08 PM, jerry@web.de wrote: > new Compiler to CMake which compiles and links OpenCL files (file ending .cl) Will that be done via `enable_language(OpenCL)`? How might it work on VS and Xcode? > What is the reason that CMake uses its own mechanism with Unix Makefiles >

Re: [cmake-developers] Fwd: Build flags not applied during compiler testing on Ubuntu

On 08/22/2018 02:43 PM, Richard Shaw wrote: > Ok, I haven't gotten any responses from the user mailing list so hopefully > someone here can help me... I responded on the user list. It's only been one day anyway. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the

Re: [cmake-developers] Quiet option for cmake

On 08/21/2018 05:04 PM, Craig Scott wrote: > A user has recently been asking about reducing the output coming from a > FetchContent population when nothing needs to be done > Because this is implemented as a sub-build, you always see the following > > -- Configuring done > -- Generating done > --

Re: [cmake-developers] Enabling SSL support by default when building CMake from source

On 08/09/2018 08:54 AM, Craig Scott wrote: > or is it just that the logic hasn't been added to try to enable > it by default if available? Mostly that. On Windows and macOS we already get SSL by default because curl just uses the OS-provided APIs. This issue occurs only when we need to find

Re: [cmake-developers] Darwin nightly builds

On 08/07/2018 02:56 AM, Martin Sander wrote: > the last nightly build for Mac in https://cmake.org/files/dev/?C=M;O=D > is dated 2018-07-30, the other systems are there. Thanks. The problem was introduced just before I took time off so the failing entry on our nightly testing dashboard went

Re: [cmake-developers] Compile flags depending on source file property

On 08/03/2018 07:12 PM, Simon Richter wrote: > string(APPEND CMAKE_CXX_FLAGS > "$,${WARN_SHADOW_OFF},${WARN_SHADOW_ON}> ") The generators put the project-/target-wide flags in a place that does not depend on the source being compiled so there would be no way to evaluate that. On some

Re: [cmake-developers] CMAKE_C_COMPILER_ARG# not documented?

On 07/19/2018 11:58 AM, Robert Dailey wrote: > I can't remember where I heard about these CMake variables, but in one > of my toolchain files I do this: > > set( CMAKE_C_COMPILER_ARG1 -m32 ) > set( CMAKE_CXX_COMPILER_ARG1 -m32 ) They are not documented because they are internal implementation

Re: [cmake-developers] ctest - how to reset default regex error list

On 07/18/2018 03:26 PM, Michal Wozniak wrote: > Is there a way to have a completely new error regex list?   No, due to the appending logic you found. Some new option would need to be added to fully replace the list. If you use CTEST_USE_LAUNCHERS the default list is much reduced. -Brad --

Re: [cmake-developers] Regenerating yacc/lex files

On 07/06/2018 10:49 AM, Devin Nakamura wrote: > I was wondering why the option to regenerate the lexer/parser sources > was removed. I tracked it down to this pull request which deals with > clang tidy warnings in the code > (https://gitlab.kitware.com/cmake/cmake/merge_requests/775). I was >

Re: [cmake-developers] Alternative CMake Syntax

On 07/04/2018 01:08 PM, Taylor Holberton wrote: > I've been thinking about designing a new syntax for CMake Fair warning: Upstream is not outright opposed to a new language but it will take a lot to make something like that upstreamable, assuming we even find time to consider it in depth. > that

Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)

On 06/26/2018 11:34 AM, Robert Dailey wrote: > I'm happy to do that. I assume you would require an MCVE for that bug? > If so it will take me considerably longer, as I don't have a lot of > time to build a reproducible example from scratch. I'll do my best, > though. Even without a MCVE it's

Re: [cmake-developers] CMake 3.12.0-rc1 is ready for testing

On 06/25/2018 01:56 PM, Raffi Enficiaud wrote: > would it be possible to add the following to the release notes? > > * FindMatlab now supports the Matlab Runtime Compiler (MCR) for >compiling and linking matlab extensions. The MCR does not >consume any license and is free to download.

Re: [cmake-developers] 3.12.0-rc1: C# project outputting as a "vcxproj" (C++ project)

On 06/26/2018 10:25 AM, Robert Dailey wrote: > To fix this issue for now I had to do this: > > set_property( TARGET ${project_name} PROPERTY LINKER_LANGUAGE CSharp ) > > I don't remember having to explicitly tell CMake that the project is > CSharp in the past; it was always able to

Re: [cmake-developers] cmake on AIX

On 06/19/2018 12:17 PM, REIX, Tony wrote: > So, it looks like cmake gets data for the CMAKE_REQUIRED_LIBRARIES > from these 2 aboves places, but it does not transform the " " blank > separators by ";" ?!! It's MariaDB's CMake code that is doing that, not CMake itself. -Brad -- Powered by

Re: [cmake-developers] cmake on AIX

On 06/19/2018 11:48 AM, REIX, Tony wrote: > However, we've found yet no information about how to: > >    a) run one test, > >    b) get more traces, ctest -R $regex_matching_tests_to_run -V >    c) know where are the logs. See the Testing/* directory. When not running in dashboard client

Re: [cmake-developers] Using pkgconf

On 06/12/2018 12:11 PM, Paul Fultz II via cmake-developers wrote: > https://github.com/pkgconf/pkgconf > > CMake could use pkgconf internally The license looks MIT-like. Please confirm that it is at least BSD-3 compatible. > find_package(zlib CONF) > > And this would look up zlib using

Re: [cmake-developers] cmake on AIX

On 06/12/2018 09:36 AM, REIX, Tony wrote: > I never saw any package built on AIX using pthread or ppc64/pthread > We have to understand why cmake is different. We use C++11 std::thread. It requires GCC's -pthread flag on AIX, and that flag changes the standard library that is used. -Brad --

Re: [cmake-developers] cmake on AIX

On 06/12/2018 03:38 AM, REIX, Tony wrote: > Did you use cmake built on AIX for building a project with it? > cmake tests are 98% OK here though that does not work with mariaDB. The test suite passes and that is mostly made up of project-like tests. It's also built using an existing CMake/CTest on

Re: [cmake-developers] cmake on AIX

On 06/11/2018 11:16 AM, REIX, Tony wrote: > We are building cmake now only with GCC (6.3.0 for now) on AIX 6.1 . > Which GCC compiler version are you using on AIX ? GCC 7.2. We previously tested with 6.1 and that worked too. > It appears that the cmake executable has been built so that it looks

Re: [cmake-developers] cmake on AIX

On 06/08/2018 11:56 AM, REIX, Tony wrote: > We'd like to know if cmake has already been ported on AIX. Yes, it has long worked on AIX. We have nightly testing on AIX 7.2 with both GCC 7.2 and XL 13.1. A couple of tests are disabled for those builds but it works in general. Since CMake 3.10 we

Re: [cmake-developers] Retrieving OS Version in CMake

On 06/05/2018 11:24 AM, Harry Mallon wrote: > Or is it best to add new fields? We should only add new fields and revise documentation to match existing behavior. > e.g. one of the below? > * OS_NAME: "Linux" -> "Fedora", OS_RELEASE: "$(uname -r)" -> "28" > * OS_RELEASE: "$(uname -r)" -> "Fedora

Re: [cmake-developers] Retrieving OS Version in CMake

On 06/04/2018 01:41 PM, Harry Mallon wrote: > Would there be a use case for a Module that could retrieve > OS name and version We do have these variables: https://cmake.org/cmake/help/v3.11/variable/CMAKE_HOST_SYSTEM_NAME.html

  1   2   3   4   5   6   7   8   9   10   >