Yep. That fixed it. Thanks!
Chuck Atkins
RD Engineer, Kitware, Inc.
-- Mathematicians are tools for turning coffee grounds into formulas.,
Paul Erdos
2012/3/14 Nicolas Desprès nicolas.desp...@gmail.com
Try with this branch:
https://github.com/polrop/ninja/tree/depfile-parser-accept-tilde
attached
- Chuck
From cfc0008206155c5244c205c3f77bba911c109b6c Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Wed, 12 Feb 2014 15:33:46 -0500
Subject: [PATCH] Add suport for custom namespaces in FindBoost.
This patch defaults to existing behavior and does NOT break
Hi Ingwie,
It depends on what exactly you're referring to. If you mean calls to
find_library and find_path, those usually have a set of known directories
and patterns that they search for. However, if you're referring to the
configure time checks line CHECK_INCLUDE_FILE and related functions,
with explanations as to why.
- Chuck
From 4c33d91f999b9030b4666be2f94d7a86c8da8527 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Fri, 1 Aug 2014 13:56:41 -0400
Subject: [PATCH] Fix broken PGI builds for liblzma.
- sha265.c is using some C99 specific features, in particular
It should be noted that the patch is really a set of workaround for PGI
compiler being broken and less to do with the code itself. If desired, I
could refactor the #if C99 test to use a CHECK_SOURCE_COMPILES at the
CMake level instead.
- Chuck
On Fri, Aug 1, 2014 at 2:22 PM, Chuck Atkins
On Fri, Aug 1, 2014 at 2:43 PM, C. Bergström cbergst...@pathscale.com
wrote:
I'm not intimately following this issue, but I can get you access to
pathcc/pathCC to see if we work on this as well.
I've got an older ekopath 4.0.9 and 4.0.10 install that you gave us a while
back when I was
+#if defined(__STDC_VERSION__) (__STDC_VERSION__ 199901L) \
Did you mean = 199901L here rather than ?
I did, that was a typo.
On 08/01/2014 02:22 PM, Chuck Atkins wrote:
I noticed the recent merge of liblzma broke the PGI compiler.
It is not surprising that there is lingering C99
environment modules on the login nodes to define it's
appropriate path and version info. I've been using this successfully on
Garnet (an XE6) and Titan (an XK7).
- Chuck
From 980483bbc2e0040273f9c7fa8df3c6bf61bba311 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Thu, 14
(CMAKE_FIND_LIBRARY_SUFFIXES .a)
endif()
...
set(CMAKE_C_FLAGS ... ${_CRAY_LINK} CACHE STRING FORCE)
set(CMAKE_CXX_FLAGS ... ${_CRAY_LINK} CACHE STRING FORCE)
set(CMAKE_Fortran_FLAGS ... ${_CRAY_LINK} CACHE STRING FORCE)
- Chuck
On Thu, Aug 14, 2014 at 6:46 PM, Chuck Atkins chuck.atk...@kitware.com
14, 2014 at 6:46 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:
I've been using CMake on Cray's quite a bit lately and some of the cross
compilation leaves a bit to be desired. No particular capability is really
missing but the foo of getting things to build and work seems to be
rather
Hey Roger, thanks for the contribution! A couple of points on find_module
convention, most of which you can find in
http://cmake.org/cmake/help/v3.0/manual/cmake-developer.7.html#modules.
Not all find modules currently shipped have been updated for these best
practices but new modules should try
universally on a generic Cray but I think it's close. I'll wait until
I get it working on the XC30 as well before I push it.
- Chuck
On Sun, Aug 17, 2014 at 4:57 AM, Rolf Eike Beer e...@sf-mail.de wrote:
Chuck Atkins wrote:
Updated to allow for static and shared libs (yes, you can use shared
I was trying to avoid the code duplication but I definitely see your
point. I'll refactor.
- Chuck
On Wed, Aug 20, 2014 at 8:55 AM, Brad King brad.k...@kitware.com wrote:
On 08/19/2014 05:43 PM, Chuck Atkins wrote:
The new hybrid mode allows the default search location to be
re-rooted
The branch has been updated on the stage to retain search path order.
- Chuck
On Wed, Aug 20, 2014 at 9:10 AM, Chuck Atkins chuck.atk...@kitware.com
wrote:
I was trying to avoid the code duplication but I definitely see your
point. I'll refactor.
- Chuck
On Wed, Aug 20, 2014 at 8:55 AM
when issues come up.
- Chuck
From 2b04ad61c583652c8755edeb3d7eb82c6b8f7bf7 Mon Sep 17 00:00:00 2001
From: Chuck Atkins chuck.atk...@kitware.com
Date: Sat, 30 Aug 2014 16:51:28 -0400
Subject: [PATCH] Added a missing config check for _Bool in liblzma
---
Utilities/cmliblzma/CMakeLists.txt | 6
I've got a UltraSPARC III machine with Solaris 10 that I just checked.
Still chugging along I bet.
Some days yes, some days no. The PSU shorted out and filled the server
room w/ smoke a few years ago. It was slated for the trash but it seemed
like a shame to toss a neat old RISC box so I
Back on topic...
Solaris 10 + SolarisStudio
http://open.cdash.org/buildSummary.php?buildid=3470493
No build failures, 4 test failures
Solaris 10 + GCC (from OpenCSW)
http://open.cdash.org/buildSummary.php?buildid=3470687
No build failures, 5 test failures
I dug more into the test
so long as -NOTFOUND is a suffix.
- Chuck
On Tue, Sep 2, 2014 at 1:37 AM, Rolf Eike Beer e...@sf-mail.de wrote:
Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins:
Back on topic...
Solaris 10 + SolarisStudio
http://open.cdash.org/buildSummary.php?buildid=3470493
No build
stage/use-consistent-regex-for-info-strings
The change seems minor enough but the impact if it breaks something is
substantial so I wanted to get a second set of eyes on this. I set out to
fix the non-working ABI detection for craycc and crayCC, which turned out
was because the cray compiler
I like the idea of reducing the extra-verbose output, and maybe I'm missing
something here but could this possibly be done with a much simpler
approach? It seems the way these double messages happen is with the
following CMake code:
message(STATUS Doing something)
# Do some stuff
message(STATUS
What happens if something else occurs in between that prints
a message? Do we tolerate
-- Doing something-- Unrelated Message
- Result
instead of
-- Doing something
-- Unrelated Message
-- Doing something - Result
Sure, why not? There's no requirement to use the NOENDL, it
Maybe it shouldn't even be a CPack thing. Maybe it should be an
install time step so that all CPack generators will contains signed
binaries if codesign is used...
I know this is a bit after the fact and I'm jumping in here pretty late,
but...
It would be nice to have package signing as
Are we still on a stage freeze until the release, or is it just a hold on
stage/next?
I ask because I've got a non-trivial branch to push to the stage for review
that re-factors how search paths are constructed for find* commands.
- Chuck
On Tue, Oct 7, 2014 at 10:43 AM, Brad King
Great, thanks!
- Chuck
On Thu, Oct 9, 2014 at 2:32 PM, Brad King brad.k...@kitware.com wrote:
On 10/09/2014 02:27 PM, Chuck Atkins wrote:
I've got a non-trivial branch to push to the stage for review
You can push it for review but please do not merge to 'next' yet.
Thanks,
-Brad
I've just pushed a branch to the stage for review:
refactor-search-path-construction , not merged to next due to the current
release hold.
Just a head's up, it's rather invasive. It's a re-factoring of how search
paths get constructed for find* commands. Up until now, search paths have
been
Just to clarify, this does *NOT* change the search order.
- Chuck
On Thu, Oct 9, 2014 at 2:45 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:
I've just pushed a branch to the stage for review:
refactor-search-path-construction , not merged to next due to the current
release hold.
Just
Following the topic branch to separately maintain each type of search path,
I'm working on adding a feature for cross-compiling to separately control
how each type of search path gets re-rooted. Currently, the options
CMAKE_FIND_ROOT_PATH_MODE_{INCLUDE_LIBRARY_PROGRAM} can be set to ONLY,
NEVER,
Can you post your toolchain file as well? Does it set any of the
CMAKE_FIND_ROOT_PATHG_MODE_{INCLUDE,PROGRAM,LIBRARY,PACKAGE} variables to
anything?
- Chuck
On Wed, Oct 15, 2014 at 10:04 AM, Guillaume Papin
guillaume.pa...@parrot.com wrote:
Hello CMake developers,
I have a cross-compiled
This looks like a reasonable way to accomplish this right now. The
underlying prioblem is that ther's no way to specify which path types get
re-rooted and which don't. Ideally you'd want to be able to specify in the
toolchain for something like this that all paths operate in ONLY mode
except
Guillaume,
Please see CONTRIBUTING.rst in the top level of the CMake source tree. If
you can please create and post a patch against cmake master then I'll work
on getting it merged into cmake next. Thanks for the bug fix!
- Chuck
On Thu, Oct 16, 2014 at 10:32 AM, Chuck Atkins chuck.atk
issues.
Thanks for the patch!
- Chuck
On Thu, Oct 23, 2014 at 4:09 AM, Guillaume Papin guillaume.pa...@parrot.com
wrote:
Please find the patch attached to this email.
Let me know if anything is wrong.
Best,
Guillaume
On 10/16/2014 05:09 PM, Chuck Atkins wrote:
Guillaume,
Please see
Merged:
c752f8f165e9b8db7bc645cc55301277cd7773be Merge topic 'find-boost-no-reroot'
- Chuck
On Sun, Oct 26, 2014 at 12:18 AM, Chuck Atkins chuck.atk...@kitware.com
wrote:
Guillaume,
Nice patch! Good detail in the commit message. I make a few minor tweaks
for typos and tense, but other
stage/fix-gcc-hppa
Add -mlong-calls for gcc on HPPA. Merged to next for testing.
- Chuck
--
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 CMake community. For more
, Nov 4, 2014 at 3:50 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Am Dienstag, 4. November 2014, 11:27:24 schrieb Chuck Atkins:
stage/fix-gcc-hppa
Add -mlong-calls for gcc on HPPA. Merged to next for testing.
Sorry,
saw this mail only after I mailed you privately because I looked
just a matter of taste if this will be narrowed to Linux or not. In any
case
please try if you can just drop the existing workarounds. The best would
probably to just replace their set() with yours and see if it works. If it
does you can remove the if(Linux) and only match for the processor.
So, it seems nothing changed. Looking at the log though, it looks like the
flags aren't even getting used. Can you check the output of uname with
it's various options? I suspect the result might not be exactly parisc.
- Chuck
On Tue, Nov 4, 2014 at 4:27 PM, Chuck Atkins chuck.atk
Hi Eike,
So, it seems that voyager has no issue, only pioneer, which I'm just taking
as coincidence from differences in various binary sizes. However, from
looking at the error log, the link line for cmake shows:
/usr/bin/c++ -Wnon-virtual-dtor -Wcast-align -Wchar-subscripts -Wall -W
-Wshadow
, 2014 at 10:54 AM, Rolf Eike Beer e...@sf-mail.de wrote:
Am Donnerstag, 6. November 2014, 10:37:25 schrieb Chuck Atkins:
Hi Eike,
So, it seems that voyager has no issue, only pioneer, which I'm just
taking
as coincidence from differences in various binary sizes. However, from
looking
I hate MATCHES ;) at least make it MATCHES ^parisc.
A reasonable compromise.
The branch has been updated, merged, squashed, and remerged to next. We'll
see what happens tonight.
- Chuck
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
, Nov 6, 2014 at 11:27 AM, Brad King brad.k...@kitware.com wrote:
On 11/06/2014 11:22 AM, Chuck Atkins wrote:
The branch has been updated, merged, squashed, and remerged to next
Thanks. This hunk:
# Determine whether this is Linux
if echo ${cmake_system} | grep Linux /dev/null 21
available for CMake:
http://open.cdash.org/index.php?project=CMakedate=2014-07-09
(they're discarded after 120 days...)
On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer e...@sf-mail.de wrote:
Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
On 11/06/2014 12:00 PM, Chuck Atkins wrote
I've added an extra configure check in KWSys for ProcessUNIX.c to test for
the required POSIX function sigaction. Previously the build would
mysteriously fail if it's not available (if building in strict ANSI mode,
for instance); now at least the failure will be at configure time and for
Hi Roger,
However, do I still need to independently check for dlfcn.h?
How do I know that I have a working dlopen?
dlopen defined in dlfcn.h is part of POSIX so generally if you're on a *nix
system then you can rely on it being there. The associated library,
however, is a different story,
Hi Adrian,
I have encountered problems installing cmake 3.3.1 on our CentOS release
6.6 cluster. It builds fine but when I come to install I get this error:
file INSTALL cannot copy file ... (this is for the copyright file).
I wasn't able to reproduce this error. Using CentOS 6.6:
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.
- Chuck
On Wed, Aug 19, 2015 at 11:59 AM, Adrian Jackson adri...@epcc.ed.ac.uk
wrote:
Hi Chuck,
Thanks for the response,
Regarding branch stage/add-link-search-static-properties-defaults
When working on a recent branch to allow default initialization of the
target properties LINK_SEARCH_(START|END)_STATIC with a corresponding
CMAKE_* variable, I encountered what I believe to be a bug in how the HP-UX
toolchains are
the C compiler is getting used as the linker for shared libs
It looks like this has been the case since CMake 2.8.7:
Easy then. I'll just fix it to use -Wl,-a like all the others. Thanks.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
the search use shared libraries exclusively, which is how all the
other platforms work. It's outside the scope of this branch but should it
be changed in a separate branch?
- Chuck
On Mon, Aug 10, 2015 at 12:00 PM, Chuck Atkins chuck.atk...@kitware.com
wrote:
the C compiler is getting used
Hi David,
I just checked the cmake.org download and was able to verify the following:
cmake-3.2.3-Darwin-x86_64.dmg - 27949121 Bytes - MD5
97c26048e9b3e242951bb5b1ff88da9e
cmake-3.3.0-Darwin-x86_64.dmg - 22628082 Bytes - MD5
232ae38586f3e6b665f9b7ac281167a0
I checked from both inside and
If you're trying to detect imposter binaries, don't use md5.
Fair enough, it was more force of habit than anything. Regardless, the
file size seems way off
I get the following for my cmake download:
$ shasum -a 256 /Users/sean/Downloads/cmake-3.3.0-Darwin-x86_64.dmg
I've implemented a new policy, CMP0065, to restrict the addition of
CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the
ENABLE_EXPORTS target property is set. This should allow us to preserve
backwards compatibility in the places it breaks existing binaries but allow
us to remove
Maybe
[TARGET_PROPERTIES prop1 value1 [prop1 value1]... ]
makes sense instead?
That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.
Good idea! I actually do like that better, but it's outside the scope of
this change. For now I'll remove the ENABLE_EXPORTS but still propagate
. Is this common to all multi-config generators or just these
two? I'm trying to determine under which circumstances the policy is even
applicable.
- Chuck
On Wed, Aug 26, 2015 at 6:30 PM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:
> Maybe
>>
>> [TARGET_PROPERTIES [ ]..
>From what I can tell, the search order is still preserved as expected.
[chuck.atkins@hal9000 testdir]$ cat TestFindProgram.cmake
set(CMAKE_PREFIX_PATH
"/FOODIR_CMAKE_PREFIX_PATH1;/FOODIR_CMAKE_PREFIX_PATH2"
CACHE STRING "" FORCE)
set(CMAKE_PROGRAM_PATH
This isn't a bug but more of a weird side effect of having your executable
named the same as an include file and adding the destination directory for
the executable in the include path. The same thing would happen if your
executable was named foo and you had "#include ". By setting
Hi Chris,
This is great! I do have a suggestion that perhaps Brad could weigh in on
(may disagree). Since your already looking at a reasonably recent minimum
requirement in your examples (3.2) and discussing bumping the minimum up to
3.4.3 even, I think it would be worthwhile to let even some
>
> I'd like to express my concerns about the proposed change. CMake strongly
> discourages using `file(GLOB)` to find source files, since file additions
> then do not automatically trigger a buildsystem regeneration.
>
I second this. The intent of the patch is to address an issue that is only
I guess it doesn't really matter but for the libraries that don't have a
single include header, should you be using these instead:
- container/container_fwd.hpp
- exception/all.hpp
- filesystem.hpp
- math_fwd.hpp (instead of math/quaternion.hpp)
- system/config.hpp
-
Hi Soumaia,
It looks like your issues are not related to CMake but to the FAST project
it'self. I see you're already in contact with the user community on their
mailing lists,
https://lists.gforge.inria.fr/pipermail/nossi-tddft-users/2017-February/06.html.
Please continue to work through the
Hi Soumaia,
The compilers are not yet in your search path so CMake can't find them.
You need to setup the intel compiler's environment first with: source
/opt/intel/bin/compilervars.sh intel64 , then CMake should be able to find
your compiler.
--
Chuck Atkins
Staff R Engineer
but
deny, ant a system level, actions you deem unsafe or harmful.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
<%28518%29%20881-1183>
On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin <egor.pu...@gmail.com> wrote:
> > What is the attack you want to stop? Wh
overrides anything I try to set for it.
--
Chuck Atkins
On Wed, Dec 7, 2016 at 10:33 AM, Brad King <brad.k...@kitware.com> wrote:
> On 12/07/2016 10:02 AM, Chuck Atkins wrote:
> > I'm trying to understand why there's both CMAKE_USE_SYSTEM_LIBRARY_FOO
> > and CMAK
Hi Gregor,
Please try to keep these sort of conversations on the dev list to ensure
that others can benefit from or contribute to the discussion as well.
I just checked on the AIX 7.2 dashboard machine. Here's the output from
all possible uname switches described in the manpage:
uname -a
AIX
e
now just using the meta-feature as the maintenace burdon for maintaining
the feature tables is too great with respect to the reward.
Hope that helps clarify the state of things.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
--
Powered by www.kitware.com
Please keep messages
Brad and I discussed this a few years ago but nothing really came of it.
Working through several find modules today, I saw many common patterns for
this and realized it should be pretty easy to implement, so here it is:
Allow the variables ENV{PackageName_ROOT} and PackageName_ROOT to be used
as
ke/Modules)
To:
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/Modules")
Or even better, don't blow away the current module path, jut append to the
front:
list(INSERT CMAKE_MODULE_PATH 0 "${CMAKE_SOURCE_DIR}/cmake/Modules")
--
Chuck Atkins
Staff R Engineer, Scientific Co
-- works
-- CMAKE_Ada_COMPILER = /usr/bin/gnatgcc
-- GNAT_MAJOR_VERSION = 6
-- GNAT_VERSION = 6.3
-- Configuring done
-- Generating done
-- Build files have been written to: /home/
khq.kitware.com/chuck.atkins/tmp/test_ada build
[chuck.atkins@hal9000 test_ada build]$
------
Chuck Atki
>
> Hi Chuck (off list):
>
Hi Alan (on list)
> but the one above I completely missed.
...
> with the hint above I should be able to figure out
> all those remaining issues on my own
Excellent! Glad to hear it. Inconsistent path quoting is a common pitfal
when writing portable CMake code.
at project and how they've decided to implement it.
------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Thu, Aug 9, 2018 at 12:23 PM REIX, Tony wrote:
> Hi,
>
>
> On AIX, when building MongoC 1.11, cmake 3.11.4 generates lib*.so files
> and lib*.a fil
69 matches
Mail list logo
