On 01/09/2017 04:59 AM, Rolf Eike Beer wrote:
> I need for several projects the ability to set CMAKE_C_STANDARD on older
> compilers
I think it would be fine to add the minimum infrastructure needed for
that and then just disable the WCDH and Tests/* pieces that don't work
with it. We could
On 01/09/2017 05:46 AM, Daniel Pfeifer wrote:
> start using TR1/C++11 library features, namely std::function, std::bind,
> std::placeholders, std::shared_ptr, std::make_shared.
I'd love to be able to start using those too, but last time I checked
they are not supported everywhere CMake builds, at
Hi Folks,
The feature freeze in 'master' for CMake 3.8 will be on Feb 1, 2017.
I may announce a freeze in 'next' sometime in the preceding week so
that we can get any remaining dashboard trouble cleaned up.
I've just returned from vacation and will try to work through the
open MRs and mailing
Hi Folks,
FYI, after today I'm heading out for vacation and will likely not
be responsive until at least Jan 9.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the
On 12/16/2016 04:35 AM, Sylvain Joubert wrote:
> The issue is that CMake appends its own "detect_leak=1"
>
> I see two possible fixes here:
> 1- Since "detect_leaks=1" is the default, we can simply not append
> it to the options and make sure the user options are last
It looks like this was
On 12/15/2016 01:57 PM, Kim Walisch wrote:
> Lets suppose I do not want to stick to my previous libtool versioning
> but instead version my library according to cmake best practices. How
> should I set VERSION and SOVERSION given my API version is 3.5 and my
> old ABI version 4:7:0. By browsing a
On 12/15/2016 11:54 AM, Kim Walisch wrote:
> I am currently in the process of switching the build system of my
> primecount project from Autotools to CMake and the shared library
> versioning in CMake is not yet clear to myself. My current project
> version (API version) is 3.5 and the libtool
On 12/12/2016 11:35 AM, Egor Pugin wrote:
> So, the original proposal is to make ALIAS & OBJECT targets local. And
> explicit GLOBAL keyword will make them global again.
An OBJECT library is just like any other target as far as the generated
build system is concerned, so it needs a globally
On 12/10/2016 04:13 PM, Egor Pugin wrote:
> Is it possible to add GLOBAL option as for INTERFACE/IMPORTED targets
> (lib/exe)?
The GLOBAL option is only available with an IMPORTED target:
https://cmake.org/cmake/help/v3.7/command/add_library.html#imported-libraries
Non-imported targets are
On 12/08/2016 01:41 AM, Craig Scott wrote:
> file names without extensions is a feature which is simply missing
> documentation or is it an undocumented feature that projects are not
> supposed to use? Since there are error messages like the above, it
> would seem that the latter would be a harder
On 12/07/2016 11:00 AM, Chuck Atkins wrote:
> Shouldn't we be able to accomplish the same same thing with
> just the CMAKE_USE_SYSTEM_FOO variable as a cache entry?
If you can refactor the logic for that then go for it. Note the
`if(CMAKE_BOOTSTRAP)` blocks. IIRC they make the bootstrap
script
On 12/01/2016 12:02 PM, Adam Rankin wrote:
> Before I dive into too many details, is anyone familiar with any issues
> surrounding this variable?
It is well-tested and known to work in general. There are still some
problems like not propagating into try_compile. It is also not sent
On 11/30/2016 02:13 PM, Serti Ayoub wrote:
> Sorry, I think it's an error on VS2015 documentation. They pretend that,
> I quote "By default, this option is off (*/Zc:inline-*)." However the
> default value is */Zc:inline*
Actually that documentation is for the MSVC compiler itself (`cl`), and
it
On 11/30/2016 02:24 PM, Serti Ayoub wrote:
> Ok, Thank you. I will check CMake 3.7.2 when released.
I updated the MR to include the changes for the v140 toolset as well.
You should be able to try the next nightly binary that appears here:
* https://cmake.org/files/dev/?C=M;O=D
-Brad
--
On 11/30/2016 02:13 PM, Serti Ayoub wrote:
> Sorry, I think it's an error on VS2015 documentation.
Okay. My previous response crossed with this one.
> Is the any way to remove this from CFlags, It seems that
>
> set_target_properties(${ProjectTarget} PROPERTIES COMPILE_FLAGS
>
On 11/30/2016 01:37 PM, Serti Ayoub wrote:
> Here:
> https://github.com/Kitware/CMake/blob/1b592b6458ce033b04ba2aa0ee4cf5ace0fd042c/Source/cmVS141CLFlagTable.h#L174
>
> I think it need also an entry : { "RemoveUnreferencedCodeData", "Zc:inline-",
> "", "false", 0}
Yes, thanks:
*
On 11/30/2016 12:29 PM, Serti Ayoub wrote:
> I'm using CMake 3.6 to generate VS2015 solution/projects.
> I found that cmake automatically add /Zc:inline for all projects
> configuration which make some of my symbols non-visible in release mode.
I'm not aware of any code in CMake that does that.
On 11/30/2016 12:06 PM, Tobias Hunger wrote:
> start over with a clean cache since the compiler changed (which is correct).
>
> After cmake::Configure(...) returns values some of the values are gone
> again. E.g. CMAKE_BUILD_TYPE changed back from "Debug" to "".
>
> Is this expected behavior?
On 11/28/2016 02:27 PM, Harry Mallon wrote:
> moving around the interface and even pushing to repos seems to be
> much slower than the equivalent thing on github.
Has it only been today or the last few days that you've noticed this?
It does feel slower today than usual. I'll check with our
On 11/28/2016 08:49 AM, Konstantin Podsvirov wrote:
> Anybody known where Brad King?
>
> Or anybody can help me to review and merge !280, !281 and !282 MRs
> into 'next' for testing?
I was on vacation for the US Thanksgiving holiday. I'll get to
these when I can.
Thanks,
-Brad
On 11/28/2016 10:25 AM, Sebastian Holtermann wrote:
> I'm going ahead then.
Thanks. BTW, please sign up for a gitlab.kitware.com account
(optionally via GitHub OAuth) so that we can include you in
discussion of related issues. For example:
* https://gitlab.kitware.com/cmake/cmake/issues/16460
On 11/25/2016 05:37 PM, Sebastian Holtermann wrote:
> There are some issues with QtAutogen that still bother me and
> that I would like to change.
Great! We currently have no dedicated maintainer for it and I have
little understanding of the tools and use cases associated with it
myself. It
On 11/24/2016 01:43 PM, Roman Wüger wrote:
> Shouldn't this be done by CMAKE_CXX_STANDARD?
Yes, this is a known problem with try_compile. It needs to learn to honor
the CMAKE__STANDARD. CMake itself works around this problem in some
cases, e.g.
*
On 11/28/2016 09:16 AM, Daniel Pfeifer wrote:
> On Mon, Nov 28, 2016 at 2:41 PM, Lode Leroy wrote:
>> The problem is that when a project contains a FOO.DLL and a FOO.EXE,
>> the cmake generator tries to build FOO.LIB for both.
>> The FOO.EXE does not need a FOO.LIB.
> Please see
On 11/19/2016 06:06 AM, Craig Scott wrote:
> can documentation be added for it
Yes, it was simply missing the docs:
https://gitlab.kitware.com/cmake/cmake/merge_requests/271
Thanks,
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 11/21/2016 11:06 AM, Dave Abrahams wrote:
> the documentation for JOB_POOLS is sparse
Yes, it is bare-bones reference documentation for someone that already
knows how Ninja job pools work. A sufficiently motivated contributor
could add more to the `Help/generator/Ninja.rst` document in a new
On 11/14/2016 04:38 PM, Roberto Regalino wrote:
> still target Android but not using VisualStudio
What generator are you now using?
> So far, I managed to create a new toolchain file containing the following:
>
> set(CMAKE_ANDROID_API 21)
> set(CMAKE_ANDROID_SKIP_ANT_STEP 0)
>
On 11/11/2016 01:51 PM, Brad King wrote:
> Okay, thanks. I'll investigate how to properly expose this information.
Please see:
https://gitlab.kitware.com/cmake/cmake/merge_requests/254
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
h
On 07/18/2016 09:14 AM, Brad King wrote:
> FindBISON: Change usage of [VERBOSE ] to [VERBOSE []]
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad2497aa
BTW, this caused a regression reported here:
* https://gitlab.kitware.com/cmake/cmake/issues/16426
Please take a look at the fi
On 11/11/2016 08:28 AM, Ruslan Baratov wrote:
> Even if they may not be needed in regular CMake code such variables can be
> useful "outside".
Okay, thanks. I'll investigate how to properly expose this information.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check
On 11/11/2016 08:11 AM, Ruslan Baratov wrote:
> What about making it public?
Please explain your use case for each piece of information you request.
Maybe there is already a way to do it.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 11/10/2016 10:46 PM, Ruslan Baratov wrote:
> the value
> "${CMAKE_CXX_ANDROID_TOOLCHAIN_PREFIX}cpp${CMAKE_CXX_ANDROID_TOOLCHAIN_SUFFIX}"
This expression is the documented way to get the paths to the Android tools.
I see no reason to add a pre-evaluated copy for every tool.
>
On 11/10/2016 10:05 AM, Ruslan Baratov via cmake-developers wrote:
> variables describing Android tools:
See:
*
https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_PREFIX.html
*
https://cmake.org/cmake/help/v3.7/variable/CMAKE_LANG_ANDROID_TOOLCHAIN_SUFFIX.html
*
On 11/09/2016 01:28 PM, maikel van den Hurk wrote:
>> Stephen Kelly wrote:
>> I believe it's because of a chicken-egg concern - the link libraries are the
>> basis for transitivity for other properties. I remember discussing that in
>> the mailing list back in the design phase.
>
> When trying to
On 11/08/2016 02:16 PM, Robert Goulet wrote:
> + if (cmSystemToolsCMakeRoot.empty()) {
> +std::string dir = cmSystemTools::GetFilenamePath(exe_dir);
Please see my sibling response for why more logic is needed.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check
On 11/08/2016 01:59 PM, Robert Goulet wrote:
> Commit: 18bfbc972fd3daf3e973f80072c4de09ec7e852b
> Add option to control 'bin' directory of CMake's own installation (#16076)
I suspect it is caused by this hunk:
> - // Install tree has "/bin/cmake" and "".
> - std::string dir =
On 11/04/2016 09:52 AM, maikel van den Hurk wrote:
> What about doing what was targeted with this bug:
> https://cmake.org/Bug/view.php?id=12435?
That issue is now tracked here:
https://gitlab.kitware.com/cmake/cmake/issues/12435
I've just added some notes to the discussion.
Steve, do you
On 10/06/2015 11:30 AM, Brad King wrote:
> On 10/04/2015 10:49 AM, Stephen Kelly wrote:
>> I wonder if you plan do resolve this part in the coming cycle? I think
>> resolving that part would help me to understand the rest of your proposal in
>> the thread.
>
> I don't
On 11/04/2016 09:02 AM, Robert Goulet wrote:
> What is the clean way to start a new project with no build flags at all.
> i.e. CMAKE_C_FLAGS, CMAKE_C_FLAGS_DEBUG, etc. all set to no value?
> Is there a way to force this for all platforms/compilers? Thanks!
There is a hook just before the flags
On 11/03/2016 06:05 PM, Christensen, Erik wrote:
> VS_GLOBAL_VCProjectUpgraderObjectName NoUpgrade
[snip]
> Really, it seems like this is a property that should be applied by
> default to any CMake generated Visual Studio projects.
Yes. Please look at cmVisualStudio10TargetGenerator.cxx to try
On 11/02/2016 04:23 PM, maikel van den Hurk wrote:
> We are trying to develop a proper C++ dependency management tool
> ...be able to get all transitive linked libraries
The cmake-server mode introduced in 3.7 was created to support tooling.
Perhaps something with that can be made to work if it
On 11/02/2016 03:32 PM, Levi Morrison wrote:
> Brad, here it is a year later and thought I would get around to
> finishing this work. Then I discovered you had already completed it!
> Thank you so much!
>
> I now have access to the 2017 Intel C++ compiler; is there anything in
> particular you'd
On 11/01/2016 04:30 PM, maikel van den Hurk wrote:
> obtain actually all transitive linked libraries of a specific target.
[snip]
> this information is only fully available during generation time.
What is an example use case for this? I don't think we can offer a
configure-time solution but
On 10/31/2016 02:26 PM, Gregor Jasny via cmake-developers wrote:
> I wonder what's the recommended workflow for CMake developers with
> commit access to stage? I'd like to use feature branches in gitlab but
> wonder how those are best merged into 'next'?
We can review in GitLab first and once
On 10/30/2016 12:01 AM, Craig Scott wrote:
> Looking at the latest CMake docs for the LINK_FLAGS and STATIC_LIBRARY_FLAGS
> target properties, neither mentions support for generator expressions.
> Is it just a case of the linker properties haven't had their documentation
> updated or do they not
On 10/26/2016 10:05 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> Which should I choose for future contributions?
GitLab, please. We recently updated CONTRIBUTING.rst to prefer
it even over patches on this list.
> My feeling is I could completely abandon the github repository
> and pull and push
On 10/23/2016 02:01 PM, Alexis Murzeau wrote:
> `$subdir\all` should use the current
> binary directory and not the current source directory like
> `$subdir\package` does.
Yes, thanks. I've applied the patch:
Ninja: Use binary dir for `$subdir/all` targets
On 10/22/2016 03:37 PM, Geoffrey Viola wrote:
> I changed a build configuration for the glv.asi site. Instead of
> Win64-vs14-dbg-x86, it’s named Win64-vs14-dbg-x86_64.
Thanks. I updated the expected build list.
-Brad
--
Powered by www.kitware.com
Please keep messages on-topic and check the
On 10/21/2016 10:30 AM, Tobias Hunger wrote:
> Yes, this change is correct. I stumbled over this myself this afternoon.
Thanks. I've submitted a MR with the prose updated too here:
https://gitlab.kitware.com/cmake/cmake/merge_requests/191
-Brad
--
Powered by www.kitware.com
Please keep
On 10/21/2016 09:51 AM, Sylvain Joubert wrote:
> Please find attached a patch that corrects a typo and a inconsistency
> in a code snippet.
Thanks!
BTW, since you last contributed we've switched from using the mailing
list for patches to using GitLab merge requests:
On 10/20/2016 04:19 PM, Robert Dailey wrote:
> Another question: Will CMake's android support only work with official
> NDK releases? Or can I expect it to function with unofficial NDKs such
> as Crystax?
We assume the official NDK layout. If an unofficial NDK has the
same layout it may work.
On 10/20/2016 03:35 PM, Robert Dailey wrote:
> So using takanome's cmake toolchain, he had support for native app
> glue. Does CMake offer support for this now? I was able to generate
> but I'm not able to load in native app glue from the NDK.
We don't currently offer a first-class interface for
On 10/20/2016 02:30 PM, Alan W. Irwin wrote:
> The deficiency I found with automoc is (as far as I can tell) it does
> not properly handle the case where the header that should be processed
> by moc is located in a different source-tree directory than the source
> file that includes that header.
On 09/23/2016 08:08 AM, Brad King wrote:
> On 09/23/2016 06:29 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
>> These are some minor changes for native support of C# targets.
>> The remaining C++ implementation will go into the Visual Studio
>> target 10 generator class.
>
On 10/17/2016 12:32 AM, Craig Scott wrote:
> Unless I'm missing something, it would seem that even though
> the documentation says FindJava.cmake sets Java_INCLUDE_DIRS
The documentation was wrong and was fixed in 3.7:
FindJava: Do not document variables we do not provide
On 10/11/2016 04:27 AM, Charles Huet wrote:
> CMake Error at CheckSourceTreeTest.cmake:355 (message):
>test fails: local source tree non-additions: use git add before committing,
>or remove the files from the source tree
The purpose of the test is to fail if there are any local
On 10/10/2016 09:39 AM, Charles Huet wrote:
> * the test CMake.CheckSourceTree does not work with Fastbuild,
> but I could not get it to work with Ninja either, maybe I
> have an environment problem ?
It works with Ninja for me. Are you building CMake out-of-source?
> * the test
On 10/09/2016 03:24 PM, Christoph Grüninger wrote:
> * or loosing the output of tests and feature summary, as both tests are QUIET.
>
> I'd prefer to write the error message to the CMakeError.log and reduce
> the output to one line. I think, the current behavior must be considered
> a bug.
The
On 10/06/2016 03:46 PM, Stephen Kelly wrote:
> Do you know what CMAKE_EXE_EXPORTS_${lang}_FLAG is? It is added to the
> linkFlags already for executables with exports.
Ah, that does appear to be the same thing.
> Is CMP0065 adding redundant flags?
The policy only affects executables without
On 10/06/2016 02:06 PM, Stephen Kelly wrote:
>> One could rename the variable in our own platform files
>> but would have to also honor the old name just in case.
>
> That wouldn't be a rename.
Sure it would. All the places that set the variable would have a new
more understandable name. We
On 10/06/2016 01:45 PM, Stephen Kelly wrote:
> I have encountered the implementation of CMP0065. As far as I can see, this
> is the only use of CMAKE_SHARED_LIBRARY_LINK_${lang}_FLAGS, and it is not
> used for shared libraries, but for executables.
Correct. It was about exporting symbols from
On 10/06/2016 08:32 AM, Charles Huet wrote:
> Do you think it is time to start the review, or should it wait
> until I have 100% of the tests passing ?
Thanks for the update. Generally my reviews for new features
mostly look at documentation, tests, style, etc. rather than
at implementation
On 10/05/2016 06:38 PM, Stephen Kelly wrote:
> The suggestion to use the first cmMakefile for these kinds of definitions is
> a good one
>
> 1) It can be documented that the variable can only be set in the top level
> 2) It is what people already do probably
> 3) It is more convenient than the
On 10/05/2016 05:35 PM, Christoph Grüninger wrote:
> Vc provides a ConfigVc.cmake.
>
> 1. When I use "find_package(Vc)", many users get warnings that neither
> FindVc.cmake nor VcConfig.cmake is found.
You can use
find_package(Vc CONFIG)
to drop the FindVc part of the message.
> 2. When I
On 10/05/2016 02:56 PM, Roman Wüger wrote:
> I tried the following to copy the required app icons to the required
> destination:
>
> configure_file(Logo.png
> ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}.dir/Logo.png COPYONLY)
That's a CMake-private directory whose location is an implementation
On 10/04/2016 05:46 PM, Stephen Kelly wrote:
> This causes problems because now the code has to read the value for each
> directory and can't assume that the value is always the same as the value
> from the top-level CMakeLists file.
Many of these are honored only in the top-level directory
On 10/03/2016 12:14 PM, Clifford Yapp wrote:
> so what we need is not actually the test names themselves,
> but a list of the executables used to run tests that are also defined
> as build targets.
[snip]
> The list we need would thus be built up to contain all COMMAND
> arguments to add_test that
On 10/03/2016 11:17 AM, Clifford Yapp wrote:
> One of the functions we are wrapping in our build with CMake's "_"
> prefix debugging mechanism is add_test. Looking at why we do that, it
> should be possible to avoid wrapping if we can get access in CMake to
> the list of all test build targets
On 09/28/2016 04:33 PM, Brad King wrote:
> After 3.7 is branched I'll announce when post-3.7
> development in 'next' is open.
I've branched 'release' for 3.7. The repository is now open for
post-3.7 development. Please rebase any open topics on 'master'
before merging to
On 09/30/2016 05:38 AM, Sebastian Holtermann wrote:
> Here are some small patches that fix the issue and add a test case.
Thanks. I've applied the patches with minor tweaks:
QtAutogen: Allow .qrc files that do not contain any file reference
On 09/28/2016 04:09 PM, Ruslan Baratov via cmake-developers wrote:
> ` -Wl,-rpath,` to CMAKE_EXE_LINKER_FLAGS.
That adds it in a way that hides its presence from CMake. CMake has its
own way to specify RPATH entries in the build tree. It will replace the
build-tree-only entries with
On 09/27/2016 08:07 PM, Junghyun Kim wrote:
> 1) Add the same sort logic of the patch(#14491) to
> cmAuxSourceDirectoryCommand.cxx
> 2) Apply my patch and remove the sort logic of patch #14491
Please patch cmAuxSourceDirectoryCommand.cxx directly. KWSys Directory
is a low-level API whose
On 09/27/2016 12:23 PM, Robert Dailey wrote:
> Brad, do you have a guide or walkthrough for the new CMake integration
> features of 3.7 that I can read?
It's documented in the cmake-toolchains(7) manual:
On 09/27/2016 11:28 AM, Florent Castelli wrote:
> Is there any plan on having their toolchain in CMake directly at some point?
No. Their toolchain files are designed to be loaded from the NDK. They
compute things relative to their own location and are meant to know exactly
what is there.
The
On 09/27/2016 12:20 AM, Junghyun Kim wrote:
> If aux_source_directory(. SRCS) or file(glob SRCS "*.c") is used
> files in SRCS are not sorted.
The file(GLOB) command sorts as of CMake 3.6:
file: Sort GLOB results to make it deterministic (#14491)
On 09/26/2016 05:50 PM, David Neto wrote:
>> I just don't want to have 2 toolchains to support, that would be really
>> terrible :(
>
> I work for Google but not in this area, and I don't know who is doing this
> support.
> I suspect this is just an accidental duplication of effort.
I have
On 09/26/2016 10:07 AM, Daniel Pfeifer wrote:
> the documentation of the ctest_build command states "Append semantics
> are defined by the dashboard server in use." I think this is not
> precise enough.
>
> The client side effect of APPEND is that CTest creates an
> Append="true" attribute in the
On 09/23/2016 06:17 PM, David Neto via cmake-developers wrote:
> I've attached a patch to add GLSL language support, compiling down to SPIR-V.
> It's based on master from this morning.
Thanks!
We are currently experimenting with a GitLab workflow on
https://gitlab.kitware.com/cmake/cmake
but
On 09/23/2016 10:30 AM, Charles Huet wrote:
> If you want to take a quick glance it should be close to what you want
Did you push an update to the fastbuild-master branch? It looks the same.
FYI, I'd like to wait until after the Oct 3 branch for the 3.7 release
before introducing changes toward
On 09/23/2016 09:01 AM, Domen Vrankar wrote:
> If nobody else is missing this flag I'll just add the flag in
> 'if(CMAKE_CXX_COMPILER_ID MATCHES "PGI")' block for this test
> for now and explain it in CPackRPM docs.
Sounds good. You should be able to use STREQUAL instead of MATCHES.
Thanks,
On 09/22/2016 03:25 PM, clin...@elemtech.com wrote:
> If there is a CMake 3.6.3, I'd like to request the inclusion of
> https://cmake.org/gitweb?p=cmake.git;a=commit;h=48624b3c
I've merged it to the 'release' branch, but I don't think there will be a 3.6.3.
We're freezing for 3.7.0 soon.
> Some
On 09/23/2016 06:47 AM, Domen Vrankar wrote:
> I have rpm tests failing on dashboard [1] and it would seem that PGI compiler
> is missing --build-id flag by default which can be added [2]
>
> Is this default behavior (missing --build-id flag) intended or simply missing
> from CMake?
>
> I'm
On 09/23/2016 06:29 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> These are some minor changes for native support of C# targets.
> The remaining C++ implementation will go into the Visual Studio
> target 10 generator class.
Great! I'd like to wait until after the 3.7 branch to start
introducing
On 09/22/2016 03:02 PM, Charles Huet wrote:
> is linux/mac support mandatory also ?
> Fastbuild does support those platforms, but the generator so far does
> not work as well (or at all) on those platforms.
I think it is okay to support only a subset of platforms at first.
Please just make the
On 09/22/2016 10:41 AM, Charles Huet wrote:
> a Fastbuild generator in the works, whose development started on CMake 3.2,
> and was pretty much abandonned for the past 5 months.
>
> I took the time to rebase it on master
Thanks for reviving it.
IIUC this refers to:
* http://fastbuild.org
*
On 09/20/2016 11:12 AM, Craig Scott wrote:
> some C++11 stuff in at least one recent merge request
We allow C++14 in code guarded by HAVE_SERVER_MODE because that is
a new/optional feature that doesn't have to work on all platforms yet.
Everything not guarded by HAVE_SERVER_MODE needs to be able
On 09/16/2016 03:37 AM, Yves Frederix wrote:
> This would work, but it would make all builds using 'cmake --build'
> more verbose as before actually starting the msbuild-build, this would
> always print an often large number of lines like:
>
> CMake does not need to re-run because
On 09/16/2016 06:32 AM, csiga.b...@aol.com wrote:
> Now it’s only up to me to understand the entire process of Makefile
> generation.
> Global/Local Generators, LocalMakeFileGenerator3 (does 3 correspond to the
> third layer of makefiles? If yes, where is 2?)
The 3 is the third generation of
On 09/15/2016 10:22 AM, Harry Mallon wrote:
> # ``OPENSSL_EXECUTABLE ``
> # The openssl binary.
Yes, this would be a reasonable addition as long as it is optional.
> 2. Should "OPENSSL_INCLUDE_DIR" be "OPENSSL_INCLUDE_DIRS" or is that
> not a hard-and-fast rule?
In general the singular name
On 09/15/2016 10:33 AM, csiga.b...@aol.com wrote:
> RC Pass 1:
>
>/foCMakeFiles\cmTC_14330.dir/manifest.res
> CMakeFiles\cmTC_14330.dir/manifest.rc
The "rc" tool is missing from the beginning of this command line.
It needs to be in the PATH within the VS environment.
-Brad
--
Powered
On 09/15/2016 09:04 AM, csiga.b...@aol.com wrote:
> That is exactly what I’m doing. I am generating a VS solution, and
> inside that I setup the debugging environment, but the process I want
> to debug is not the VS solution generation, but the NMake Makefile
> generation process.
Okay, misread
On 09/14/2016 10:10 AM, Mate Nagy-Egri via cmake-developers wrote:
> How do you setup Visual Studio to debug through a config/gen process?
The easiest way is to use one of the VS IDE generators rather than
NMake Makefiles. Then in the IDE use the properties dialog on the
"cmake" target to set up
On 09/14/2016 11:25 AM, Yves Frederix wrote:
> replace it by sequentially running two almost identical msbuild
> commands: first targeting ZERO_CHECK and then targeting whatever
> target the user requested, picking up any changes to the project
> files.
For `cmake --build` we already need to
On 09/15/2016 03:24 AM, Minze Zwerver wrote:
> I could merge the codelite enhancements into the original
> codelite generator
That would be preferred.
> Would something like -DCMAKE_CODELITE_USE_TARGETS=ON be an
> acceptable way, if not, how should one influence the generator ?
Yes.
FYI, the
On 09/14/2016 09:05 AM, Chi Hsuan Yen wrote:
> I use `git send-email -1` to send the previous email. Is it correct?
> Or I should attach the patch manually in a new email instead? Thanks.
Either is fine. I've applied the patch:
FindPython{Interp,Libs}: Add version 3.7
On 09/13/2016 07:42 AM, Ruslan Baratov via cmake-developers wrote:
> Will it be okay if CMake will optionally depend on OpenSSL?
> Or other third party crypto library?
Currently the only place that needs it is through `curl`, and
that uses either OpenSSL or the Windows-native or macOS-native
APIs
On 09/08/2016 03:17 PM, Brad King wrote:
> There are only a few older than that (2.8.7, 2.8.9, 2.8.11).
> I'll try to get those updated soon and report back. Then we
> can move to 2.8.12 for now.
Done. I temporarily added a CMake-time warning for submissions
using lower than 2.8.12.
On 09/12/2016 07:22 AM, Andreas Roth wrote:
> i was wondering if you plan to support C# as language.
No one upstream is working on this but there has been some progress
by others. One should be able to find discussion in the list archives.
-Brad
--
Powered by www.kitware.com
Please keep
Hi Folks,
The feature freeze in 'master' for CMake 3.7 will be on Oct 3, 2016.
I may announce a freeze in 'next' 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 09/10/2016 11:34 AM, Craig Scott wrote:
> have a crack at adding the required functionality to my fixtures branch
> so that regular tests are skipped if setup tests fail
[snip]
> limit the new functionality just to fixtures where the required
> behaviour is well defined.
Sounds good to me.
301 - 400 of 3527 matches
Mail list logo
