On 05/30/2018 10:18 AM, Gurulev, Dmitry wrote:
> ITT comes w/ VTune app. in binary form
> (/opt/intel/vtune_amplifier_2018.2.0.551022/lib64/libittnotify.a)
Is there a header file too?
> VTune is not CMake based distributive, no way to add cmake
> package config to it.
It's possible to provide a
On 05/30/2018 10:05 AM, Gurulev, Dmitry wrote:
> It might be a binary package, no way to provide package config.
I don't understand. Does it provide header files? Does it provide
a "linktome.lib" file?
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ
On 05/30/2018 09:54 AM, Eric Noulard wrote:
> protoc can already do something like that but it spits out a makefile
> includable file.
>
> see --dependency_out=FILE option.
That may work well for the Ninja generator at least. See the
add_custom_command `DEPFILE` option.
One day it would be
On 05/29/2018 04:00 PM, Alexander Neundorf wrote:
>> In order to handle implicit dependencies like that implied by
>>
>> import "MyBase.proto";
>>
>> then they would somehow need to be extracted from source content.
>
> Would that have to be implemented similar to the C dependency scanning ?
On 05/30/2018 01:56 AM, Gurulev, Dmitry wrote:
> what about stand-alone ITT?
That project's upstream should be able to provide a package configuration
file as well.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 05/29/2018 10:30 AM, Gurulev, Dmitry wrote:
> Although IntelSEAPI (which contains ITT sources) is a CMake based
> library, ITT itself might be used as standalone binary library, so
> finding module still makes sense
If the upstream is CMake-friendly it should provide a CMake Package
On 05/15/2018 03:45 PM, Alexander Neundorf wrote:
> I think to do it properly, there would have to be a dependency scanning for
> proto files like there is for C/C++ headers.
In order to handle implicit dependencies like that implied by
import "MyBase.proto";
then they would somehow need
On 05/25/2018 04:27 PM, Kyle Edwards wrote:
> ctest_start()
> ctest_configure()
> ctest_build()
> ctest_test()
> ctest_submit()
>
> What happens if ctest_configure() fails (for example, because CMake
> failed to find a needed library)? Does the entire script stop right
> there? Or does it
On 05/20/2018 02:21 PM, Gößwein Matthias / eeas gmbh wrote:
> I found a strange behavior within the object libraries in the upcoming
> CMake 3.12 (I used 3.11.20180519-gdb88f for testing).
Thanks for trying it out!
> If I have for example two object libraries, which are used in one
> executable:
On 05/17/2018 05:56 AM, Kinga Kasa wrote:
> cmake running for hours and hours (stuck at saying Configuring done,
> eventually it will finish, but it runs for hours).
That's not expected. Even on projects with tens of thousands of
source files and thousands of libraries and executables it
On 05/15/2018 03:22 AM, Stephen Kelly wrote:
> So, the answer for cmake might be that CMake can learn to extract that
> stuff, but ignore certain cases like imports within ifdefs.
We'd need to do the extraction from already-preprocessed sources.
This is how Fortran+Ninja+CMake works.
On 05/07/2018 12:01 PM, Stephen Kelly wrote:
> Hopefully Brad or someone else can provide other input from research already
> done.
I'm not particularly familiar with what compiler writers or the modules
standard specification expects build systems to do w.r.t modules.
However, IIUC at least at
On 05/01/2018 06:33 AM, Harry Mallon wrote:
> I just noticed that COMPILE_OPTIONS is 3.11.0 only. I can’t understand
> from the docs which of COMPILE_OPTIONS or COMPILE_FLAGS is preferred
> and why I might use one or the other.
COMPILE_OPTIONS for targets has existed for a long time. What is
new
On 04/27/2018 02:36 PM, Patrick Stotko wrote:
> We can also continue the discussion at GitLab to avoid bothering the
> others with such technical details if you like.
Fine with me. I mainly wanted it brought up here to gain more attention.
Interested followers can now jump to the issue:
On 04/26/2018 07:18 PM, Craig Scott wrote:
> Perhaps it was an oversight that newer target_... commands don't have the same
> restriction as target_link_libraries(), but it is a very useful oversight!
> As the linked blog article explains, it allows much better modularity of the
> project.
Yes,
On 04/11/2018 12:25 PM, Jayakumar, Lenindarbi wrote:
> Is the below issue solved in latest release 3.11.0 ?
> Could you please confirm?
The fix discussed elsewhere in the thread:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1691
is in 3.11.0. The `@` is no longer hard coded. I
On 04/11/2018 10:48 AM, Gößwein Matthias / eeas gmbh wrote:
> CMake Error: The inter-target dependency graph contains the following
> strongly connected component (cycle):
> "lib1" of type OBJECT_LIBRARY
> depends on "lib2" (strong)
> "lib2" of type OBJECT_LIBRARY
> depends on "lib1"
On 04/04/2018 03:30 AM, Mathieu Westphal wrote:
> Is there a way, using cmake, to start a gui command on windows
> and have the gui shows up ?
```
execute_process(COMMAND cmd /c notepad)
```
> If not, is this intended?
Yes. Otherwise console windows appear for everything.
CreateProcessW is
On 03/29/2018 02:38 PM, Michal Wozniak wrote:
> I thought of adding clang-tiny to our build process.
> Is it possible to exclude third-party libraries?
The variable used to activate it:
https://cmake.org/cmake/help/v3.11/variable/CMAKE_LANG_CLANG_TIDY.html
works by initializing a property
On 03/26/2018 04:24 AM, Cameron Palmer wrote:
> However, setting the property BUILD_WITH_INSTALL_RPATH on or off doesn't
> change anything as far as I can tell. The target is still linked with
> -headerpad_max_install_names and the linker still complains.
Oops, I mixed up functionality with other
On 03/26/2018 08:07 AM, Craig Scott wrote:
> Am I missing something, or is the following result surprising to others as
> well:
>
> set(somevar YES)
> if ("somevar")
> message("Get here if CMP0054 is OLD (seems okay)")
> else()
> message("Get here if CMP0054 is NEW (surprising?)")
>
On 03/21/2018 06:01 PM, Craig Scott wrote:
> I swear I asked this a while back and there was an example given
Maybe here:
* https://gitlab.kitware.com/cmake/cmake/merge_requests/1581
> Does anyone know of a specific example scenario where an
> INTERFACE IMPORTED library is the right choice over
On 03/17/2018 01:29 AM, Alan W. Irwin wrote:
> In the latter case
>
> Set properties on a target ==> Set properties on targets
>
> and
>
> list all the files you want to change ==> list all the targets you
> want to change
It is the latter. See MR here:
On 03/12/2018 10:36 AM, Cameron Palmer wrote:
> So after a bit of hacking it seems that Cmake should provide something like:
>
> CMAKE_OSX_BITCODE_ENABLE
For reference, this refers to a previous post:
Bitcode and CMake
https://cmake.org/pipermail/cmake/2018-March/067191.html
with the
On 03/08/2018 03:16 AM, Craig Scott wrote:
> The test is passing, but it ends with a build failure trying to build
Currently `cmGlobalGenerator::Build` doesn't check the return
code from the "make clean" step and just moves on to "make".
It fails only if there is a problem launching the build
On 03/05/2018 02:32 PM, Claus Klein wrote:
> I have problems to build cmake an msys2.
> It can be found at http://www.msys2.org.
We have nightly testing for MSYS2's MinGW toolchain that compiles
to a native Windows binary, including the bootstrap script:
On 02/21/2018 05:50 AM, Craig Scott wrote:
> it seems like NEON should also be supported for arm64-v8a
>
> Is this just a case of the CMake docs need to be updated?
Likely yes. Please also verify that the implementation works
as expected. Is the NEON support for arm64-v8a perhaps dependent
on
On 2/16/2018 7:43 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> 1) The debug version crashes in
I don't know if we've ever built a debug configuration against this Qt.
> This application failed to start because it could not find or load
> the Qt platform plugin "windows" in "".
We statically link
On 2/13/2018 11:28 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> I try to do a CMake build with static C runtime and a static Qt 5.10.0
Make sure Qt is configured with both `-static` and `-static-runtime`,
and that it is built with the same compiler as CMake. See the command
used below to configure
On 02/06/2018 10:03 AM, Claus Klein wrote:
> why different default behaviors in Nina and Makefile generators?
The Makefile dependency generation works totally differently and
can't do system headers well at all. One day perhaps they should
be ported to use a depfile approach too and then a
On 02/06/2018 03:19 AM, Claus Klein wrote:
> IMHO: This make ninja slower without much user benefit!
For reference, the change was made for CMake 3.6 here:
https://gitlab.kitware.com/cmake/cmake/commit/6d74e7870b8804a5af0bc395a9fbb45c1b3d26a4
The benefit is that sources recompile when system
Hi Folks,
I've branched 'release' for 3.11. The repository is now open for
post-3.11 development. Please rebase open merge requests on 'master'
before staging or merging.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 02/02/2018 10:05 AM, Saeed, Khurram wrote:
> In this generator we are generating .project and .cproject files
> for Nucleus ReadyStart application.
Are those files driving the actual build?
These days the way to support IDEs tends to be using the
cmake server mode:
Hi Rich,
FYI there is discussion about providing backtraces from the server
to clients here:
https://gitlab.kitware.com/cmake/cmake/issues/17539
It was originally done in CMake 3.10.0 but caused major memory bloat
and so was reverted.
> One of the things we need is to be able to get the
On 01/22/2018 07:54 AM, Brad King wrote:
> Yes, that use of `@` should be made configurable.
>
> I'll take a look when I get a chance.
The IBM XL compiler needs this too to use `-qoptfile=`.
See fix here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1691
-Brad
--
On 01/23/2018 04:55 AM, Tobias Hunger wrote:
> Any objections from the core team about enabling server-mode with a
> build directory only? I can send in a patch, it is simple to add this.
Fine with me.
This should be allowed only when the build tree already exists.
Thanks,
-Brad
--
Powered by
On 01/19/2018 09:25 AM, Jayakumar, Lenindarbi wrote:
> I have to use response file for both includes and objects.
> Tasking compiler expects -f as Response file link flag for both.
> But cmake produces command line for objects using -f and includes using @.
>
> I prefer to get it fixed in
On 01/19/2018 07:30 AM, Craig Scott wrote:
> * In most cases, the various files are appending rather than prepending
> to the existing contents of the XXX_FLAGS_INIT variables.
It was once just setting them. The `_INIT` variables were not originally
meant to be set by project code or toolchain
On 01/17/2018 04:14 PM, Claus Klein wrote:
> 1.) Is ist possible to change the object or/and the dependency file
> name generated for ninja?
No one has needed to before because currently-supported compilers all
have options to specify the output file name.
> 2.) Why generates cmake the
On 01/17/2018 03:52 AM, Jayakumar, Lenindarbi wrote:
> Response file link flag “CMAKE_C_RESPONSE_FILE_LINK_FLAG” is not customizable
> for include paths.
> The @ symbol is hardcoded in “cmMakefileTargetGenerator::AddIncludeFlags”
In case the compiler and link driver want different response file
On 01/08/2018 07:26 AM, Sebastian Holtermann wrote:
> Then I'm going to refactor cmQtAutoGeneratorMocUic
> to use a libuv event loop internally.
Great. Take a look at Source/cmUVHandlePtr.h for some C++ helpers.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the
On 01/06/2018 02:31 AM, Sebastian Holtermann wrote:
>>> 2) Use libuv instead
>
> I just saw the libuv library in the CMake sources.
>
>> libuv for process management is on the list. I think it is waiting for
>> porting to all of CMake's platforms to actually happen.
>
> Does that mean it's
On 11/22/2017 06:37 AM, Máté Ferenc Nagy-Egri wrote:
> Well, my impression was that it is generally for external tools to be
> aware of the build process, or the commands CMake executes.
`compile_commands.json` was a hack to support clang-tidy and similar tools
and was never meant to be a general
On 11/21/2017 05:31 AM, Máté Ferenc Nagy-Egri via cmake-developers wrote:
> can we export custom commands into compile_commands.json?
The purpose of that file is to make compile commands available to
tools like clang-tidy. Custom commands do not belong in it.
Its purpose has been largely
On 11/18/2017 03:08 AM, Tobias Hunger wrote:
>> I'm not familiar with that IDE, but in order to be directly supported
>> by a generator its native build system would need to support everything
>> in CMake's code model (static/shared/exe binaries, custom commands, etc.).
>
> This is only necessary
On 11/16/2017 12:56 PM, llvm 999 wrote:
> I would like to know if there is any plan to add support for it.
Not of which I'm aware.
> Or perhaps, there is some technical issue related to this particular
> IDE that makes it impossible to support such IDE.
I'm not familiar with that IDE, but in
On 11/07/2017 03:50 PM, Alan W. Irwin wrote:
>> # Do build of PLplot as a ctest of CMake.
>> set(CMake_TEST_CONTRACT_PLplot:BOOL=ON)
>
> Why could I set garbage in the cache
> file as above with the result that that garbage was read
> and ignored with no error message? Isn't that a CMake bug?
On 11/06/2017 05:24 PM, Alan W. Irwin wrote:
> https://open.cdash.org/viewTest.php?onlypassed=5131552
> Is there something I have missed in those results or something wrong?
Your script now has:
```
set(dashboard_cache "
...
# Do build of PLplot as a ctest of CMake.
On 10/30/2017 11:38 AM, Brad King wrote:
> FYI I'm refactoring the way the existing contract tests work to make
> it easier to add and maintain one for PLplot. Once that is done I'll
> look at actually adding PLplot and report back here.
I've opened a MR to add the PLplot contract
On 11/01/2017 07:30 PM, Taylor Holberton wrote:
> I noticed that CMake strips the trailing forward slash from an
> include directory when assembling an object file with NASM.
> The trailing slash is required with NASM.
This will likely require `Modules/CMakeASM_NASMInformation.cmake`
to get some
On 10/30/2017 12:54 PM, Alan W. Irwin wrote:
> superficially appears that some of the tests are timing out.
No, they are passing. The time status column is for trying to detect
tests that suddenly jump in time required. It's based on some kind of
model of the time that takes a while for CDash
On 10/26/2017 01:10 PM, Brad King wrote:
> Thanks. I'll take a look at adding a test to build that when I get
> a chance.
FYI I'm refactoring the way the existing contract tests work to make
it easier to add and maintain one for PLplot. Once that is done I'll
look at actually adding
On 10/26/2017 09:58 PM, Alan W. Irwin wrote:
> While trying to set up a clean Experimental dashboard, I have noticed
> a minor spelling issue (furhter ==> further in
> a comment in cmake_common.cmake).
Fixed, thanks.
> unset(ENV{CXXFLAGS})
> unset(ENV{CFLAGS})
> unset(ENV{FFLAGS})
>
On 10/26/2017 11:53 AM, Alan W. Irwin wrote:
> git://git.code.sf.net/p/plplot/plplot
Thanks. I'll take a look at adding a test to build that when I get
a chance.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
On 10/25/2017 03:43 PM, Alan W. Irwin wrote:
> In any case, my dashboard submission is working now using
>
> ctest -S ~/cmake/Dashboards/Scripts/CMakeScripts/my_dashboard.cmake -VV
Great!
> See the raven-without-fixed-IP
The `-without-fixed-IP` suffix has no meaning to readers on CDash.
>
On 10/24/2017 05:47 PM, Alan W. Irwin wrote:
> Since I essentially never get CMake build errors when building
> CMake by hand using the bootstrap method, I assume these build
> errors are due to some issue with how I set up my_dashboard.cmake.
The difference is that the script is testing the
On 10/24/2017 05:10 PM, Alan W. Irwin wrote:
> It appears cmake_common.cmake only provides the capability of changing
> the --parallel option for the bootstrap script. Must I change that
> script in order to specify additional bootstrap options I normally use
> such as --qt-gui --system-curl or
On 10/25/2017 04:46 AM, Rolf Eike Beer wrote:
> This very much looks like a change I had in a few weeks ago but removed
> from there because of exactly those compile failures.
This is all under discussion here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1402
The errors this time
On 10/13/2017 12:08 AM, Alan W. Irwin wrote:
> Accordingly Bill Hoffman suggested to me off-list
> some time ago that I configure a CMake dashboard submission that
> builds the master HEAD CMake version and tests it with a build and
> test of PLplot similarly to what is done for Trilinos.
>
>
On 10/12/2017 11:50 PM, Alan W. Irwin wrote:
> I just completed a comprehensive test of PLplot on Linux (Debian
> Jessie) using a cmake version that I built myself from the
> CMake-3.10.0-rc2 source code using the bootstrap method. The result
> was a complete success
Great, thanks for testing!
On 10/02/2017 11:48 AM, Brad King wrote:
> I'll announce when post-3.10 development is open.
I've branched 'release' for 3.10. The repository is now open for
post-3.10 development. Please rebase open merge requests on 'master'
before staging or merging.
> Meanwhile the following
On 09/12/2017 11:53 AM, Brad King wrote:
> The feature freeze in 'master' for CMake 3.10 will be on Oct 2, 2017.
> I may announce a freeze in 'stage' sometime in the preceding week so
> that we can get any remaining dashboard trouble cleaned up.
In order to get 'master' ready to branch
On 10/02/2017 07:24 AM, Nikola Smiljanic wrote:
> Thanks Brad, so setting CXX_EXTENSIONS to off will switch me to
> 'standard' compliant mode?
Yes. It can be done for all targets on creation by using the
CMAKE_CXX_EXTENSIONS variable:
On 10/01/2017 08:29 PM, Nikola Smiljanic wrote:
> I'd like to know why CMake uses 'gnu' flags when setting C++ standard.
> I find this very surprising as 'gnu' mode enables non standard extensions?
Setting the standard level should not affect the extensions, and the compiler's
default mode
On 09/26/2017 12:55 PM, clin...@elemtech.com wrote:
> https://bugreports.qt.io/browse/QTBUG-63442
Please take a look at the proposed fix:
https://codereview.qt-project.org/#/c/207327/
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 09/27/2017 08:18 AM, Raffi Enficiaud wrote:
> For cross-compiling a project on iOS or iOS simulator, and since those 2
> platforms are still Darwin, I believe that:
>
> * from a user perspective:
>* CMAKE_SYSTEM_NAME should be set to "Darwin"
>* CMAKE_SYSTEM_VERSION should be set to
On 09/26/2017 05:05 PM, Raffi Enficiaud wrote:
> Is it possible to source the default setup and to override some parts
> when a toolchain is given on the command line?
The toolchain file is loaded very early, before any of the platform
information files. It is supposed to provide information,
On 09/26/2017 11:15 AM, Sebastian Holtermann wrote:
> "cmake --help-policy CMP0071" already mentions SKIP_AUTOMOC.
> Should the warning mention SKIP_AUTOMOC as well?
Yes, please. It removes an indirection.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check
On 09/26/2017 11:07 AM, Sebastian Holtermann wrote:
>> AUTOMOC: Ignoring GENERATED header file(s):
>>
>> "/path/to/ui_SomeFile.h"
>> "/path/to/qrc_AnotherFile.cpp"
>
> You can set the source file property SKIP_AUTOMOC on the GENERATED files.
Sebastian, please revise the policy warning to mention
On 09/26/2017 09:32 AM, clin...@elemtech.com wrote:
> CMake Warning (dev) in claro/navigation5/CMakeLists.txt:
> Policy CMP0071 is not set: Let AUTOMOC and AUTOUIC process GENERATED files.
> Run "cmake --help-policy CMP0071" for policy details. Use the cmake_policy
> command to set the
On 09/19/2017 07:50 PM, Peter Mitrano wrote:
> Does this sound reasonable? Would this be something I could contribute?
Yes, see:
https://gitlab.kitware.com/cmake/cmake/blob/master/CONTRIBUTING.rst
for instructions.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic
On 09/15/2017 09:22 AM, Edward Diener wrote:
> A gui environment like Visual Studio does provide
> functionality to just compile one or more source files, and it also
> provides functionality to just build an executable from one or more
> source files without actually running that executable.
On 09/15/2017 10:55 AM, Steven Velez wrote:
> I am assuming that the lack of response indicates that there has not
> been much thought or interest expressed along this dimension of the feature.
>
> Would a better way to approach this be to implement a prototype and create a
> WIP MR?
Can you
On 09/14/2017 11:33 PM, Edward Diener wrote:
> Boost Build has tests for running an application successfully or not,
> for compiling one or more source files successfully or not, and for
> building one or more source files into an exe or not. These tests in
> Boost Build are the run/run-fail,
Hi Folks,
The feature freeze in 'master' for CMake 3.10 will be on Oct 2, 2017.
I may announce a freeze in 'stage' sometime in the preceding week so
that we can get any remaining dashboard trouble cleaned up.
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check
On 08/29/2017 05:28 PM, Robert Dailey wrote:
> One other thing: Is there a way to make find_package() default to
> CONFIG mode? Right now it seems to search MODULE first, then CONFIG.
> But right now the only way to enable config is to explicitly use the
> CONFIG option or make sure CMake can't
On 08/29/2017 12:21 PM, Robert Dailey wrote:
> 3. Second find_package() happens, but "AlreadyInCache" is true (line
> 28 in cmFindPathCommand.cxx) this time, so it doesn't search for it
> again.
>
> Hard to tell where the bug is here. I'd argue that AlreadyInCache
> shouldn't be set to true since
On 08/29/2017 11:50 AM, Robert Dailey wrote:
> Wow even if I set ZLIB_ROOT, FindZLIB.cmake *still* won't find my zlib
> over the one provided by the Android NDK...
>
> Although I was able to get this working fine on Windows, it does not
> work with the NDK's toolchain file.
That's because the
On 08/29/2017 11:33 AM, David Cole wrote:
> That's correct:
>
> find modules do what they want, and most do not pay attention to
> CMAKE_PREFIX_PATH.
CMAKE_PREFIX_PATH *is* used by find modules.
The find modules use find_* commands, and those use CMAKE_PREFIX_PATH.
See the documentation of
On 08/29/2017 10:55 AM, Brad King wrote:
> On 08/29/2017 10:48 AM, Robert Dailey wrote:
>> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
>> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
>
> I'm not sure how CMAKE_FIND_ROOT_P
On 08/29/2017 10:48 AM, Robert Dailey wrote:
> CMAKE_PREFIX_PATH: E:/code/frontend/msvc_2015/third_party/installed
> CMAKE_FIND_ROOT_PATH: E:/code/frontend/msvc_2015/third_party/installed
I'm not sure how CMAKE_FIND_ROOT_PATH's path re-rooting interacts with
drive letters on Windows.
-Brad
--
On 08/29/2017 10:27 AM, Robert Dailey wrote:
> I'm relying on the two variables above to control this behavior, but
> CMAKE_INSTALL_PREFIX doesn't work well for both purposes.
Use CMAKE_PREFIX_PATH, not CMAKE_INSTALL_PREFIX, to control
the set of prefixes that find commands search.
-Brad
--
On 08/27/2017 02:24 PM, Taylor Holberton wrote:
> I just finished the first release of a cross platform, minimalistic
> Make implementation.
>
> It was made specifically to run CMake generated Makefiles on Linux
> and Windows (haven't tested on macOS yet).
>
> It's on GitHub
On 08/24/2017 03:19 AM, Manu wrote:
> I have fixed it but I am struggling with the new policy. The
> behaviour change goes into cmSystemTools::GetRealPath implementation
> and SystemTools has no context, so I am not sure how to check the policy.
The policy would have to be checked higher in the
On 08/23/2017 05:56 PM, Sebastian Holtermann wrote:
> It seems that in CMake 3.9/AUTOGEN the VS generator uses the *_autogen
> target more often than necessary (it could use PRE_BUILD instead).
>
> Let's assume a target `B` that depends on
> - a *GENERATED* file `FA`
> - a linked library `LA`
>
On 08/23/2017 11:27 AM, maikel van den Hurk wrote:
> change ... optimisation from O3 (CMake internal setting) to O2.
If you want to change the default flags instead of only adding
(prepending) to them then you need to set all the flags by
setting the cache entry directly. A toolchain file that
On 08/23/2017 09:56 AM, maikel van den Hurk wrote:
> I was wondering why there is no ability to define
> CMAKE__FLAGS(_) within a CMake Toolchain file, but still
> benefit from the CMAKE__INIT_FLAGS(_) detected from CMake
> internals.
This has been possible since commit v3.7.0-rc1~392^2
On 08/23/2017 05:15 AM, Craig Scott wrote:
> how long until we up the minimum Visual Studio version from 2010
> to at least 2013?
That's only blocked on me finding time to update the nightly testing
infrastructure. It requires moving several builds to other machines.
-Brad
--
Powered by
On 08/21/2017 09:53 AM, Sebastian Holtermann wrote:
> it looks like C++11 is now a requirement for CMake itself.
Yes. We just merged this:
https://gitlab.kitware.com/cmake/cmake/merge_requests/1132
but you beat us to the announcement.
> But does this mean *all* the nice features from the
On 08/17/2017 12:20 PM, Anh Huynh wrote:
> If I want the user to provide inputs to select GPU targets
[snip]> Should I have the user set a definition before using find_package> and
checking for that definition?
Yes. Document it as an input variable that can be set prior to the
call. Either the
On 08/15/2017 04:33 PM, Daniel Pfeifer wrote:
> With !977 merged, it is possible to base ccmake and cmake-gui on top
> of the cmake serverShall we proceed in this direction?
Yes! That will be a nice separation. It will also reduce the number
of places we have to set up `class cmake`
On 08/13/2017 11:36 AM, Raffi Enficiaud wrote:
> -DALL_DEPENDENCIES="${ALL_DEPENDENCIES_FILES}"
That is actually an unquoted argument whose value contains literal quotes.
See the cmake-language(7) manual for details on the syntax. Switch it to
On 08/14/2017 06:35 AM, Manu wrote:
> Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP ...)
> behaviour changed. Now it reports symbolic link timestamp instead of pointed
> file timestamp.
Can you track down when that happened?
> patch to fix both get_filename_compoment and
On 08/11/2017 03:18 AM, Валентин Хирный wrote:
> I've tried to prepare cmake configuration file for Embarcadero bcc64 compiler.
> For my practice I chose the name Embarcadero64 for new compiler because
> bcc64 is clang based compiler.
Does `bcc64` have a radically different command line interface
On 08/08/2017 08:08 AM, Raffi Enficiaud wrote:
> I have looked a bit to the Android toolchains, and I have to say I found
> those quite complicated as a first reading :)
This note may help:
https://gitlab.kitware.com/cmake/cmake/issues/16708#note_300971
I don't think iOS will need all the
On 08/07/2017 05:27 PM, Eric Wing wrote:
> I think that would be a mistake because it seems that the only purpose
> of this change would be so you could bypass CMake and try to directly
> invoke some kind of command line invocation on the dynamic library
> inside the .framework bundle.
The ld(1)
On 08/05/2017 07:58 PM, Craig Scott wrote:
> target_link_libraries(foo PRIVATE "-framework AppKit")
>
> Strangely, with the library quoted as above, the embedded space
> is not escaped, leading to the (desirable but surprising) result
Link flags starting in `-` are treated as a raw part of
On 08/01/2017 09:53 PM, Alan W. Irwin wrote:
> Yes, that patch works for PLplot.
Great, thanks for testing.
> Assuming you are going to commit this patch is it something that
> needs further extensive testing or will it go into one of the
> CMake-3.9.x releases?
Yes:
On 07/23/2017 10:20 AM, Craig Scott wrote:
> maybe it's worth considering renaming these single underscore
> internal macros and functions?
Projects that rely on the undocumented feature depend on being
able to call the original function by prepending the single
underscore. We can't change the
On 07/26/2017 06:02 AM, Alan W. Irwin wrote:
> enable_language(Java)
FWIW this language support is quite limited, is not well tested,
and has long been superseded by `UseJava.cmake`. I suggest porting
away from it in PLplot. That will fix this too.
> 62c4cb4b6f0cdb2be2729362133f850d6fe96c20 is
101 - 200 of 3527 matches
Mail list logo
