On Mon, Apr 04, 2016 at 09:07:09 +, melven.roehrig-zoell...@dlr.de wrote:
> After thinking about my patch I worried it could break other compilers.
> So, here is a more defensive version that shouldn't interfere with anything
> else.
>
> Explanation:
> CMAKE_Fortran_COMPILER_ID was correctly
On Fri, Apr 01, 2016 at 15:39:26 +0100, Samir Benmendil wrote:
> Use the git config `http.sslVerify=false` to disable strict ssl for git
> commands.
> ---
> Changes in v2:
> - git_options is now a list
Thanks.
I've pushed this into next for testing.
--Ben
--
Powered by www.kitware.com
Ple
On Fri, Apr 01, 2016 at 16:20:10 +0200, Nils Gladitz wrote:
> This might be a use case for the newish IN_LIST operator?
>
> e.g. if(Fortran IN_LIST _LANGUAGES_)
How have I missed this‽
*goes and makes minimum version of all CMake projects 3.3* ;)
--Ben
--
Powered by www.kitware.com
Please ke
On Fri, Apr 01, 2016 at 10:58:50 +0100, Samir Benmendil wrote:
> +# set git_options
> +if(NOT tls_verify)
> + set(git_options -c http.sslVerify=false)
> +endif()
Looks good overall, but could this be turned into a pattern like:
set(git_options)
if (NOT tls_verify)
list(APPEND git_o
On Fri, Apr 01, 2016 at 12:44:29 +, melven.roehrig-zoell...@dlr.de wrote:
> Patch for a problem with find_package(BLAS/LAPACK) on Windows for pure
> Fortran projects reported by me in
> https://cmake.org/Bug/view.php?id=16039.
Thanks. My patch looks similar (differs in variable names basically
On Tue, Mar 29, 2016 at 10:24:26 -0400, Brad King wrote:
> Might a user want to change the url used locally? If so then we
> need a way to turn off the automatic sync, though I think making
> it default is reasonable.
I suppose it is possible, but if you're modifying submodules behind
ExternalPro
Hi,
I'd like to bump the minimum ExternalProject requirement to 1.8.1 from
November 2012 (current requirement is 1.6.5 from October 2009). The
reason is that this release introduced the `git submodule sync
--recursive` command (the command existed before, but the flag is new in
1.8.1). The usecase
On Tue, Mar 15, 2016 at 10:06:12 -0400, Brad King wrote:
> add_custom_command(OUTPUT foo.h ...)
> add_library(foo foo.c foo.h)
> add_library(bar bar.c)
> target_link_libraries(bar foo)
>
> The order-only dependency of `bar.c.o` on the target `foo` is just
> in case `bar.c` needs to include
On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
> Did you have a chance to review my patches?
So I looked at it today, and it looks good overall. A few niggles:
+inline bool cmEndsWith(const std::string& str, const std::string& what)
+{
+ assert(str.size() >= what.size());
Probab
On Tue, Mar 08, 2016 at 12:36:31 +0100, Nicolas Desprès wrote:
> Did you have a chance to review my patches?
Sorry, not yet. I hope to have a peek at it today or tomorrow.
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/C
On Tue, Mar 08, 2016 at 14:36:38 -0700, Kael Dai wrote:
> I have a test that outputs multiple lines and want to use
> set_tests_properties with the PASS_REGULAR_EXPRESSION property to check
> different lines in the output. I've tried doing
>
> set_tests_properties(test1 PROPERTIES PASS_REGULAR_EXP
On Mon, Feb 08, 2016 at 15:29:50 +, Antonio Pérez Barrero wrote:
> thanks for feedback, I'll rework the patch. I was planning to actually
> submit three patches covering the following:
>
> * Version checking
> * Interface variables rename, keeping backwards compatibility.
> * Fix a bug when se
On Tue, Feb 02, 2016 at 09:29:10 +0100, Antonio Perez Barrero wrote:
> From: Antonio Perez Barrero
>
> Check found libraries version to match user required version, including
> EXACT match.
>
> Protobuf compiler executable version is check to be aligned with found
> libraries, raising a warning
On Thu, Jan 28, 2016 at 21:32:17 +0100, Pau Garcia i Quiles wrote:
> Unfortunately, using INTERNAL cache variables requires me to modify the
> third-party library, which is exactly what I do not want to do.
How so?
set(THIRD_PARTY_FLAG MY_VALUE CACHE INTERNAL "Setting for
${parent_project}")
On Thu, Jan 28, 2016 at 15:15:58 -0500, Taylor Braun-Jones wrote:
> That's too bad. I understand the perspective of the Ninja developers,
> but it's not clear to me what the proposed alternative should be.
> Should CMake be using the subninja[1] keyword to include the
> build.ninja of External Proj
On Thu, Jan 28, 2016 at 21:07:13 +0100, Pau Garcia i Quiles wrote:
> I think it's just a matter of adding an "internal note" saying "OK, I'm
> going to namespace variables from now on" in cmAddSubdirectoryCommand when
> add_subdirectory contains NAMESPACE, and then modifying the literal of the
> va
On Mon, Jan 25, 2016 at 16:06:47 +0300, Vyacheslav Barinov wrote:
> I try to detect paths to some tools using CMake and got the following problem:
> if the tool I try to check has 611 (-rw--x--x) rights FIND_PROGRAM reports the
> file does not exists.
>
> For instance my /bin/mount in Gentoo has s
On Fri, Jan 22, 2016 at 17:34:03 +0100, Nicolas Desprès wrote:
> I have pushed a first draft of the patch here:
>
> https://github.com/nicolasdespres/CMake/commit/67a4faad47378c07c97a29dd229d6f9fa500763b
>
> I have tested with a small project and it looks good.
Looks like a good start to me as w
On Mon, Jan 11, 2016 at 16:47:03 -0500, Taylor Braun-Jones wrote:
> I have another INTERFACE property use case that is not whitelisted, but
> should be: VERSION
VERSION is a special property for libraries. Particularly the name for
the file with the actual content of the library (the SOVERSION and
On Wed, Jan 06, 2016 at 19:26:11 +0100, Nicolas Desprès wrote:
> Is that variable already available or a name suggestion? I cannot find any
> reference to it neither in the source nor in the documentation.
It's a suggestion.
> This is acceptable for me since I have a custom generator that would w
On Wed, Jan 06, 2016 at 11:14:32 +0100, Nicolas Desprès wrote:
> To enable this type of generation, the "top/" directory must be passed to
> CMake somehow. An environment variable or a CMake variable called
> CMAKE_NINJA_TOP_BUILD_DIR would do the trick.
I think CMAKE_NINJA_OUTPUT_PATH_PREFIX woul
On Tue, Jan 05, 2016 at 09:18:49 +0100, Bartosz Kosiorek wrote:
> That's great news.
> What is the branch name/link to these improvement?
> Is it possible to push these improvements partially?
Because the changes are so pervasive, I'd like for the branch to be
bisectable, so every commit should pa
On Sun, Dec 27, 2015 at 22:04:14 +0100, Dimitar Yordanov wrote:
> I agree with you. Running valgrind directly on the cmake binary
> provides useful information: I can see which internal cmake functions
> are used the most and consume most of the time.
>
> Nevertheless, I think it would be useful t
On Thu, Dec 17, 2015 at 13:54:08 -0500, David Cole wrote:
> I agree with Brad, the --timeout command line parameter should only
> set/override the variable CTEST_TEST_TIMEOUT. The behavior w.r.t. test
> TIMEOUT properties should be left as is for this change.
This behavior also makes sense to me.
On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
> On the cmake general list, Brad recently answered my original query on this
> subject and appears to agree with me that that ctest --timeout
> option should always have the highest priority, i.e., override any
> timeout set by the proje
On Tue, Dec 15, 2015 at 10:33:38 -0800, Alan W. Irwin wrote:
> On 2015-12-15 11:20-0500 Ben Boeckel wrote:
> > I think, instead, that --min-timeout and --max-timeout options might be
> > better which allow you to say "this machine is slow; tests may take
> > longer (
On Mon, Dec 14, 2015 at 23:01:31 -0800, Alan W. Irwin wrote:
> On the cmake general list, Brad recently answered my original query on this
> subject and appears to agree with me that that ctest --timeout
> option should always have the highest priority, i.e., override any
> timeout set by the proje
On Fri, Dec 11, 2015 at 22:13:46 +0100, Alexander Neundorf wrote:
> On Friday, December 11, 2015 14:44:39 Ben Boeckel wrote:
> ...
> > Option 3:
> >
> > set(CACHE) (and any other cache-touching behavior) does *nothing*
> > with the cache if a local va
On Thu, Dec 10, 2015 at 08:50:10 -0500, Brad King wrote:
> BUG: change in how set cache overrides local definitions. Should mainly be a
> NOP change for most cases
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f52d37c2
So Brad and I discussed today the reasons behind this change. Here i
On Thu, Dec 10, 2015 at 21:20:21 +0100, Alexander Neundorf wrote:
> On Wednesday, December 09, 2015 17:35:28 Ben Boeckel wrote:
> > So some behavior I was unaware of until today came up:
> >
> > set(var ON)
> > option(var "description" OFF)
> >
day: first configure
!= subsequent configure, so I don't see the confusion as being *less*
after the fix since any existing tree wouldn't say "2" either, but I
suppose it was something about dashboards doing clean builds.
> On 12/09/2015 05:35 PM, Ben Boeckel wrote:
>
Hi,
So some behavior I was unaware of until today came up:
set(var ON)
option(var "description" OFF)
message("var: ${var}")
outputs "OFF" for the first configure and "ON" for subsequent
configures. This is because set(var CACHE) does unset(var) *if* the
cache was touched. This is not
On Wed, Dec 09, 2015 at 09:19:45 +0100, Attila Krasznahorkay wrote:
> I myself am on the side of simplicity. Using regular expressions would
> allow us to do what I want. But if >95% of the people using this new
> possibility would use it exactly like I plan to, then implementing it
> in a more com
On Tue, Dec 08, 2015 at 10:09:13 +0100, Attila Krasznahorkay wrote:
> In the end I applied the following patch to CMake 3.4.1 locally to
> speed it up for my use case very significantly. Of course this is not
> a patch that could be applied to CMake for a general audience. But I
> do think that if
On Fri, Nov 20, 2015 at 17:22:33 +, Robert Goulet wrote:
> I'm looking to find where is MSVC_VERSION defined in CMake? I added a
> new platform support that builds in Visual Studio, but MSVC_VERSION is
> not defined for my new platform and I would like to do it just like we
> do for standard Wi
On Wed, Nov 18, 2015 at 13:22:07 -0600, Ryan Houdek wrote:
> I was wondering if adding a new policy that disables the undocumented
> feature of cmake where it appends extensions to filenames when searching
> for files would be something that would actually be accepted to be merged
> if someone spen
On Wed, Nov 18, 2015 at 10:44:24 -0500, Brad King wrote:
> The code
>
> if(test_type STREQUAL "TEST")
>
> could still trigger CMP0064 warnings. We can use the style
How would this trigger the warning? Do we look for keywords *after*
variable expansion? Or is it triggering on the right-hand "T
On Tue, Nov 03, 2015 at 10:39:06 +, Stuermer, Michael SP/HZA-ZSEP wrote:
> At the moment only visual studio generator and only version 2013 is
> accepted/implemented. It should not be a big task to enhance it to
> support 2015 as well. It would be great to have at least nmake, but I
> have abs
On Wed, Oct 21, 2015 at 01:53:42 +0600, Ruslan Baratov wrote:
> On 20-Oct-15 21:42, Ben Boeckel wrote:
> > On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers
> > wrote:
> >> * I don't want to patch every script. To be precise I prefer to &qu
On Tue, Oct 20, 2015 at 04:56:47 +0600, Ruslan Baratov via cmake-developers
wrote:
> * I don't want to patch every script. To be precise I prefer to "Fix
> something in one place so it works 100% and forget about it" then "Every
> time I start creating script I should remember that..."
The "one
On Thu, Oct 15, 2015 at 22:58:29 +0300, Ruslan Baratov via cmake-developers
wrote:
> Test: https://github.com/forexample/date-resolution-test
> Log: https://travis-ci.org/forexample/date-resolution-test/builds/85021483
> Any other ideas?
I patched make locally to output the mtimes used when it f
On Thu, Oct 08, 2015 at 17:16:33 +0200, Daniel Wirtz wrote:
> @ben / "I honestly don't think configure time git information is all
> that useful anyways"
> in our scenario, the configure time information is actually more
> relevant. we use the "superbuild" scheme and also provide
> a "support" ta
On Thu, Oct 08, 2015 at 13:10:54 +, Ryan Pavlik wrote:
> One addition I would have liked to have but haven't had time to do yet: the
> ability to have a add custom command-based build time generation, instead
> of our in addition to the CMake time generation. Some projects take a very
> long ti
On Mon, Oct 05, 2015 at 12:50:41 +0200, Daniel Wirtz wrote:
> thanks for the feedback, i've included most of it.
>
> Regarding the configure/build issue: that indeed is inconvenient and may
> cause irritation. on the other side, if there has been git activity
> fussing with any source files affe
On Sun, Oct 04, 2015 at 16:47:40 +0200, Stephen Kelly wrote:
> The existing CMake feature deals with compilation, but does not deal with
> linking.
A generic target_link_options() is necessary for other things as well,
such as:
* -fsanitize=address needs to be passed to the linker to add -las
On Thu, Oct 01, 2015 at 07:56:11 +0300, Tuukka Pasanen wrote:
> As said there ain't official Cmake for SDL2-family and several other. I
> don't believe we are experts of most of them but just wondering should
> there be some kind common effort to provide some of them in same place
> and try to p
On Wed, Sep 30, 2015 at 10:22:47 -0400, Brad King wrote:
> With regard to SDL2, the proper way to make it find-able with CMake is
> for SDL2 to provide a CMake packaging files themselves as part of their
> own distribution (since they build with CMake):
Just to note, SDL2 also has build systems fo
On Fri, Sep 25, 2015 at 17:32:24 +0200, Daniel Wirtz wrote:
> Hello all,
> here's my proposal for the git convenience functions, see
> http://public.kitware.com/pipermail/cmake/2015-September/061516.html
>
> i've also created a pull request
> https://github.com/Kitware/CMake/pull/185 (before i r
On Tue, Aug 25, 2015 at 09:59:14 -0500, Peter List wrote:
> // required to avoid run found with adb logcat
> extern void Java_org_libsdl_app_SDLActivity_nativeInit(JNIEnv* env, jclass
> cls, jobject obj);
There's an SDL_android_main.c file you need to compile. I have a
personal Android/NDK app her
On Fri, Aug 21, 2015 at 10:35:58 -0400, David Cole via cmake-developers wrote:
> Honestly, KWSys has always seemed like a boost-avoidance mechanism
> from an outsider's perspective. Perhaps it should be replaced with
> boost equivalents in projects that need to be packaged for Fedora.
>
> I assume
On Wed, Aug 19, 2015 at 20:56:16 -0400, Ben Boeckel wrote:
> $ # install with CMAKE_INSTALL_PREFIX as wanted
Sorry, "install" -> "build".
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki
On Wed, Aug 19, 2015 at 12:37:42 -0400, Chuck Atkins wrote:
> Instead of an install, try to run "make package". This will create
> cmake-3.3.1-Linux-x86_64.tar.gz that you should be able to extract anywhere
> you want to install it to.
Alternatively:
$ # install with CMAKE_INSTALL_PREFIX as
On Sun, Aug 16, 2015 at 21:52:26 -, James Johnston wrote:
> d. If the answer to (c) is yes, should that keyword become the default,
> subject to a new policy? (And introduction of a different NO_RESPECT_UMASK
> keyword).
FWIW, the install(1) tool does not respect umask by default (and ha
On Thu, Aug 13, 2015 at 20:36:55 -0600, Orion Poplawski wrote:
> There is concern in Fedora that the kwsys code has become too large to
> be an acceptable copylib. However, as cmake is constructed at the
> moment it would be a huge undertaking for the Fedora packagers (mostly
> me) to remove it
On Mon, Jul 27, 2015 at 14:56:26 -0400, Brad King wrote:
> The error on not exporting private dependencies has received
> complaints before. Technically it is necessary to properly
> populate the -rpath-link flag when a shared library has
> dependencies that are not next to it and not in a standar
Hi,
I've pushed two new branches to stage (and merged to next):
- trace-expand: adds --trace-expand option to cmake which expands
variable references in --trace output.
- ctest-add_subdirectory-crash: fixes a crash present since 2008(!)
when using add_subdirectory from TEST_INCLUDE_FI
On Tue, Jul 21, 2015 at 10:03:42 -0400, Brad King wrote:
> Okay. I've made a note about this issue to make sure it is fixed before 3.4.
>
> Meanwhile I have another comment on genex support in the OUTPUT_DIRECTORY
> properties. Currently the properties support both
>
> {ARCHIVE,LIBRARY,RUNTIME
On Mon, Jul 20, 2015 at 16:01:29 -0400, Clifford Yapp wrote:
> I've put both in and added the man pages - progress so far attached.
> Are there any other docs that list target properties, or are the rst
> files the canonical sources for property docs?
Those should be it.
> For testing these prope
On Fri, Jul 17, 2015 at 14:16:34 -0400, David Cole wrote:
> get_cmake_property is more like "strictly well-pre-defined, read only
> (ish), built-into CMake" properties. Note there is no
> set_cmake_property... What docs are you looking at that you think have
> a bug...?
Help/command/get_cmake_prop
On Fri, Jul 17, 2015 at 12:18:18 -0400, David Cole wrote:
> Are you saying there should be a named GLOBAL property with this
> information in it...?
>
> It seems like more of a fit to get_cmake_property.
Indeed. It seems there is no overlap between `get_property` and
`get_cmake_property`. Which m
On Thu, Jul 16, 2015 at 13:27:12 -0400, David Cole via cmake-developers wrote:
> This would best be added as a "TARGETS" variant of the existing
> http://www.cmake.org/cmake/help/v3.3/command/get_cmake_property.html
> command.
>
> (In my opinion...)
The get_property command would also need to han
On Wed, Jul 08, 2015 at 14:42:03 -0400, Brad King wrote:
> On 07/08/2015 02:35 PM, Stephen Kelly wrote:
> > "Since Apple is the only vendor implementing the language
> > right now, the compiler id can be just `Apple`."
>
> Even if another vendor implements it the one we're identifying
> will still
On Wed, Jul 08, 2015 at 14:11:44 -0400, David Cole wrote:
> Interesting. So, sort of, but not really. At least not explicitly.
Well, the docs state it, but there's no error for setting CMP0010 OLD
and CMP0053 NEW at the same time other than the CMP0053 parser turning
any code which would have requ
On Wed, Jul 08, 2015 at 19:53:31 +0200, Tamás Kenéz wrote:
> Is this restriction, that an OBJECT library can't be on the left hand side
> of
> target_link_libraries, is it a hard, final decision? Or is this issue
> open for a possible improvement which would allow this and would forward
> the link
On Tue, Jun 09, 2015 at 11:24:03 -0400, David Cole via cmake-developers wrote:
> Is there a single example of a policy wherein the OLD behavior has
> actually been removed?
Technically, yes. CMP0053 as NEW ignores CMP0010's setting and treats it
as NEW (because the new parser doesn't implement the
On Thu, May 21, 2015 at 09:31:41 -0400, Taylor Braun-Jones wrote:
> So I added another workound for that:
>
> if(${CMAKE_GENERATOR} MATCHES ".* Makefiles$")
> set(environment_build_flags "$ENV{MAKEFLAGS}")
> endif()
>
> add_custom_target(coverage_data
> COMMAND env --unset=MAKEFLAGS
On Thu, May 07, 2015 at 13:06:26 -0400, Ben Boeckel wrote:
> Merged as update-ctest_build-docs.
Thanks for the followup commit for clarifying the docs. I hit the
problem where CTEST_BUILD_COMMAND makes CTEST_BUILD_FLAGS get ignored.
The new wording makes it much clearer :) .
--Ben
--
Powe
On Thu, May 07, 2015 at 09:12:43 -0400, Brad King wrote:
> IIRC when use of -i was introduced we actually used -k first and found
> it to be inadequate for the needs at the time. Since requirements seem
> to have changed I think switching to -k is okay.
I've merged this into next as replace-make-
On Wed, May 06, 2015 at 13:53:42 -0400, Brad King wrote:
> On 05/05/2015 04:11 PM, Ben Boeckel wrote:
> > Does anyone have any issue with remove `-i` from the implicit flags from
> > makefile generators with the build command (ctest_build)?
>
> We can change it with ex
On Wed, May 06, 2015 at 11:15:55 -0400, Brad King wrote:
> On 05/05/2015 05:44 PM, Ben Boeckel wrote:
> > Should CMakeConfigurableFile.in have a trailing newline?
>
> Prior to a fix in CMake 3.1:
>
> CMakeConfigurableFile: Remove excess newline.
> http://cmake.
Hi,
Should CMakeConfigurableFile.in have a trailing newline? I recently hit
a problem where my contents were made using:
foreach (...)
set(contents "${contents}new stuff\n")
endforeach ()
set(CMAKE_CONFIGURABLE_FILE_CONTENT "${contents}")
configure_file(...)
but this cau
Hi,
Does anyone have any issue with remove `-i` from the implicit flags from
makefile generators with the build command (ctest_build)? The problem is
occuring in a "superbuild" where `-i` gets put into the MAKEFLAGS
environment variable and then causes bogus configure errors in the
subproject (her
On Mon, Apr 06, 2015 at 19:08:37 +0200, Stephen Kelly wrote:
> AFAICT, CMake does still know the command line in your output-target-flags-
> once-in-ninja branch.
>
> You just need to compute two outputs - once for writing the Ninja file
> (containing variables), and again for writing the conten
On Sat, Apr 04, 2015 at 14:32:51 +0200, Stephen Kelly wrote:
> On 04/02/2015 10:29 AM, Anton Makeev wrote:
> > Just to make sure, you mentioned that this file should be deprecated with
> > this new metadata.json,
> > is that correct?
>
> I'm not sure I mentioned that, just that it's an externally
On Tue, Mar 10, 2015 at 01:25:16 +0100, Aleix Pol wrote:
> >>"output" :
> >> "/home/kde-devel/tmp/llvm/build/lib/libLLVMPowerPCInfo.a",
> >
> > Can this be a list?
> It's 1 output per target, no?
Not on Windows with .dll and .lib splits.
> >>"sources" : [ "/list/of/cpp/fi
On Sat, Mar 07, 2015 at 22:20:26 +0100, Gregor Jasny wrote:
> Suprisingly "new-style" tests support generater expressions
> also within all test properties. Add a test for that.
This patch isn't necessary. The docs mention that here:
http://www.cmake.org/cmake/help/v3.0/command/add_test.html
On Sat, Feb 28, 2015 at 17:59:55 +0100, Adam Strzelecki wrote:
> target_precompiled_header( )
>
> target_precompiled_header( SHARED
>
> )
Could we rename this? Currently target_* functions are all related to
usage requirements and these are not usage
On Wed, Feb 25, 2015 at 22:57:13 +0100, Stephen Kelly wrote:
> > What I envision for the future is:
> >
> > add_library(objlib OBJECT ...)
> > target_compile_definitions(objlib PUBLIC MYDEF)
> > target_sources(objlib INTERFACE $)
>
> Do you envision that as the idiomatic way to declare object
On Mon, Feb 23, 2015 at 13:44:13 -0500, Ben Boeckel wrote:
After discussion with Brad here, the current, tentative, plan is as
follows:
- When creating $ generator expressions, if the name is a
target, add $ as well. This will help the exporter find
targets which need exporting from
n discuss that in a different thread. I think
> it's probably a good idea.
OK, I'll just leave it with allowing OBJECT libraries to use the genex.
Further branches to address other usage can come later.
> Ben Boeckel wrote:
> > Sure, I *can*, but it's also not how I've us
On Mon, Feb 23, 2015 at 21:05:01 +0100, Stephen Kelly wrote:
> Is there a reason to disallow that? We might guess it will be possible to
> install object libraries in the future.
We could also lift the restriction then. I'm fine with just dropping the
patch. Basically without it, all it blocks is
On Mon, Feb 23, 2015 at 09:47:06 -0500, Brad King wrote:
> Currently it is just a different implementation of the same use cases.
> However, logic for processing the gcov output moves from CTest to CDash.
> The ctest_submit(CDASH_UPLOAD) command doesn't just upload files, it
> contacts a new CDash
On Wed, Feb 11, 2015 at 09:44:26 -0500, Brad King wrote:
> We already guarantee that CMAKE__COMPILER is set, so we could indicate
> failure simply by having it not set.
Well, the problem is that that is valid in Ninja. It might be available,
but it isn't going to be useful.
> Also one would need
On Tue, Feb 10, 2015 at 21:48:39 -0800, Alan W. Irwin wrote:
> Sorry, but I still think the general Ninja problems with Fortran are
> orthogonal to this general language support issue. Or are you
> implying that enable_language(OPTIONAL) works for Ninja now for all
> languages other than Fortran?
On Tue, Feb 10, 2015 at 17:15:33 -0800, Alan W. Irwin wrote:
> As the originator (almost 6 years ago) of this bug report I am still
> very much interested in a fundamental solution to give a WARNING
> message rather than an error if there is any issue with a compiler.
This patch makes it only an e
On Fri, Feb 06, 2015 at 13:15:45 -0500, Ben Boeckel wrote:
> Looks like compiler_feature_detection will need to normalize the
> _GLIBCXX_USE_CXX11_ABI preprocessor define as well:
>
> http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
Followup (LWN comments will
On Mon, Feb 09, 2015 at 11:09:32 -0500, Robert Maynard wrote:
> > We are pleased to announce that CMake 3.1.2 is now available for download.
>
>
> I'm getting this now building cmake 3.1.2 for Fedora Rawhide with gcc 5.0.0:
>
> 32: Detecting CXX compile features - done
> 32: Testing feature : cx
On Fri, Feb 06, 2015 at 15:00:50 -0800, Michael Smith wrote:
> Non-prefixed names shouldn't be used for 64-bit architectures. The only
> major releases with 64-bit support are 2.0.0 and 2.1.5, and both use the
> x64- prefix. New patch attached.
What about AArch64?
> Follow-up question: Why doesn'
Looks like compiler_feature_detection will need to normalize the
_GLIBCXX_USE_CXX11_ABI preprocessor define as well:
http://developerblog.redhat.com/2015/02/05/gcc5-and-the-c11-abi/
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cm
On Fri, Feb 06, 2015 at 07:01:55 +0100, Christoph Grüninger wrote:
> would you mind to tackle issue 9220 "enable_language( OPTIONAL)
> signature does not work correctly"? It's a shame that CMake cannot
> properly detect optional Fortran for more than 5 years! The workaround
> from Eigen works f
On Mon, Feb 02, 2015 at 23:47:15 +0100, Roman Wüger wrote:
> I think the change is also required for the following line (line 424):
>
>
>
> if(!default_config && !configurationTypes.empty())
>
>
>
> Because here the ?default_config? could also be a valid pointer with an
> empty content/stri
On Mon, Feb 02, 2015 at 09:56:26 -0500, Robert Maynard wrote:
> Forwarding to CMake Developers as this looks to be bug.
Oops, indeed. Pushing out a patch.
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware
On Mon, Jan 26, 2015 at 22:39:00 +, Alex Merry wrote:
> Maybe it's just my colour scheme - I'll have a play with the colour settings
> when I have some free time.
FWIW, I use neverland-darker, a 256-color scheme. Looking at it with an
8-color scheme does indeed have it all being the same. 'La
On Mon, Jan 26, 2015 at 11:00:05 -0500, Ben Boeckel wrote:
> Odd; attached is an HTML dump from Vim for what I see (:TOhtml) where
> variable expansions are highlighted in strings just like outside of
> strings.
Probably help if I actually attached the file :/ .
--Ben
Title: ~/code/de
On Sat, Jan 24, 2015 at 15:29:51 +, Alex Merry wrote:
> On Wednesday 21 January 2015 16:17:35 Ben Boeckel wrote:
> > List of improvements to the syntax file:
> >
> > - drop support for < 7.0 (which is 7.5 years old now);
> > - add support for Lua-style commen
Hi all,
Any Vim users out there who would like to try out the changes I've made
to the Vim files shipped with CMake can grab it from either stage
(vim-support-overhaul) or my GitHub fork[1]. It is not in next yet since
I expect further changes to come and that would only make unnecessary
churn on
On Tue, Jan 20, 2015 at 10:42:47 -0500, Daniel Levin wrote:
> This wrapper script cannot be common, because for each kind of build env
> variable set will be different. So it need to be created at CMake
> generation time saving current QNX* env variables into this wrapper script.
> So next time you
On Wed, Jan 14, 2015 at 16:20:52 +, Robert Goulet wrote:
> To be honest I haven't spent much time trying to learn 'imported'
> libraries with CMake. It was already difficult to deal with commands
> that don't support generator expressions versus those that does. It
> wasn't clear which commands
On Mon, Jan 12, 2015 at 11:40:19 -0500, Matthew Woehlke wrote:
> Anyway, your regex is overcomplicated; I'd think it would be just
> '^2[.]1([.]|$)'. (I'd be a little hesitant to allow '2.1a' to match
> '2.1'... is that '2.1 alpha' or 'release "a" after 2.1'?
Depends on whether it's a "normal" pro
On Fri, Jan 09, 2015 at 20:18:25 +0100, Rolf Eike Beer wrote:
> Matthew Woehlke wrote:
> > On 2014-10-03 03:35, Rolf Eike Beer wrote:
> > > find_package(foo 2.0 EXACT) means EXACT, i.e. only "2.0" is allowed. In
> > > most cases this behavior is not the one that one would expect or need.
> > > Most
101 - 200 of 316 matches
Mail list logo
