Hi Tony,
I believe I somewhat misunderstood what appears to be two separate issues
here: 1: how to get your build to generate the static and shared libraries
and 2: the library format doesn't seem correct. Regarding 1, it will be
project specific if the project's build designed to simultaneously p
roject and how they've decided to implement it.
------
Chuck Atkins
Staff R&D 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 l
Cray, PGI) are
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&D Engineer, Scientific Computing
Kitware, Inc.
--
Powered by www.kitware.c
>
> 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.
iler: -- 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 A
ake/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&D Engineer,
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 i
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 powe
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&
Hi Karl,
>> I believe that the AddressSanitizer should normally stop with a non-zero
> error code right after the first error.
>
> I have many tests within each executable test application, forcing the
> application to exit on the first error is not optimal since it means I
> cannot get an overvie
LIBRARIES force overrides anything I try to set for it.
------
Chuck Atkins
On Wed, Dec 7, 2016 at 10:33 AM, Brad King 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 CMAKE_US
acing CMAKE_USE_SYSTEM_FOO and not deal with the seperate
CMAKE_USE_SYSTEM_LIBRARY_FOO?
--
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
orting the
requested standard.
------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183
On Thu, Dec 1, 2016 at 12:02 PM, Adam Rankin wrote:
> Hello all,
>
>
>
> I have switched my project over to using the CMAKE_CXX_STANDARD variable
atures but
deny, ant a system level, actions you deem unsafe or harmful.
------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
<%28518%29%20881-1183>
On Sun, Aug 21, 2016 at 2:02 PM, Egor Pugin wrote:
> > What is the attack you want to stop? What are bad scri
>
> The library builds using CMake and rather than using more code to find
> itself, it should instead create a package configuration file which
> contains the exact information CMake needs to use its install tree. See
> the docs:
>
>
> https://cmake.org/cmake/help/latest/manual/cmake-packages.7.ht
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
CMAKE_INCLUDE_
>
> 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
pr
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
- type_erasure
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 of
>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
"/FOODIR_CMAKE_PROGRAM_PATH1;/FOODIR_CM
generators. 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
wrote:
> Maybe
>>
>> [TARGET_PROPERTIES [ ]... ]
>>
>
>
> Maybe
>
> [TARGET_PROPERTIES [ ]... ]
>
> 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
the policy and
I've implemented a new policy, CMP0065, to restrict the addition of
CMAKE_SHARED_LIBRARY_LINK__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 it b
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
wrote:
> Hi Chuck,
>
> Thanks for the response, yes it is installin
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:
[
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
wrote:
> > the C compiler is getting used as the linker
>
> > 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:
http
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
> 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
> 0282d6f139f5292
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 outside
Hi Roger,
> However, do I still need to independently check for ?
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, hence CM
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
reasonabl
e earliest CDash results available for CMake:
http://open.cdash.org/index.php?project=CMake&date=2014-07-09
(they're discarded after 120 days...)
On Thu, Nov 6, 2014 at 5:27 PM, Rolf Eike Beer wrote:
> Am Donnerstag, 6. November 2014, 12:44:12 schrieb Brad King:
> > On 11/06
then
cmake_machine_parisc=false
else
cmake_machine_parisc=true
fi
fi
- Chuck
On Thu, Nov 6, 2014 at 11:27 AM, Brad King 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
>
> 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:
http://w
Nov 6, 2014 at 10:54 AM, Rolf Eike Beer 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
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 -W
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 Atki
>
> 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 proce
ronment.
- Chuck
- Chuck
On Tue, Nov 4, 2014 at 3:50 PM, Rolf Eike Beer 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
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
info
Merged:
c752f8f165e9b8db7bc645cc55301277cd7773be Merge topic 'find-boost-no-reroot'
- Chuck
On Sun, Oct 26, 2014 at 12:18 AM, Chuck Atkins
wrote:
> Guillaume,
>
> Nice patch! Good detail in the commit message. I make a few minor tweaks
> for typos and tense, but othe
don't anticipate any issues.
Thanks for the patch!
- Chuck
On Thu, Oct 23, 2014 at 4:09 AM, Guillaume Papin 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, Ch
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
wrote:
&
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 HI
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-compil
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, or
Just to clarify, this does *NOT* change the search order.
- Chuck
On Thu, Oct 9, 2014 at 2:45 PM, Chuck Atkins
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.
>
> Ju
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 incr
Great, thanks!
- Chuck
On Thu, Oct 9, 2014 at 2:32 PM, Brad King 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.
>
>
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 wrote:
> O
>
> 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 signin
>
> 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 NO
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
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 will
t's not the
case, it works so long as "-NOTFOUND" is a suffix.
- Chuck
On Tue, Sep 2, 2014 at 1:37 AM, Rolf Eike Beer wrote:
> Am Montag, 1. September 2014, 14:35:41 schrieb Chuck Atkins:
> > Back on topic...
> >
> > > Solaris 10 + SolarisStudio
> >
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
>
> > 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
we can know right away when issues come up.
- Chuck
From 2b04ad61c583652c8755edeb3d7eb82c6b8f7bf7 Mon Sep 17 00:00:00 2001
From: Chuck Atkins
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 ++
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
wrote:
> I was trying to avoid the code duplication but I definitely see your
> point. I'll refactor.
>
> - Chuck
>
>
> On Wed, Aug 20,
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 wrote:
> On 08/19/2014 05:43 PM, Chuck Atkins wrote:
> > The new hybrid mode allows the default search location to be
> > re
I just pushed a branch to the topic stage to address a long standing issue
I've had with cross compiling and toolchain files. The branch,
add-find-root-system_only-mode , adds a new SYSTEM_ONLY mode to the root
path search options. Currently the possible options are:
- ONLY - re-roots all sea
work 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 wrote:
> Chuck Atkins wrote:
> > Updated to allow for static and shared libs (yes, you ca
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 t
ot; 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
> wrote:
>
>
tly
# only looks for static libraries
set(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 ".
rm file that uses information from
the loaded 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
Fr
Whoops, my mistake. Fixed.
- Chuck
On Mon, Aug 4, 2014 at 10:03 AM, Brad King wrote:
> On 08/04/2014 09:57 AM, Chuck Atkins wrote:
> > Given that it was ported though, I'd say the better fix would be
> > to remove the C99 version entirely and always use the C89 version
&g
>
> > +#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 m
On Fri, Aug 1, 2014 at 2:43 PM, "C. Bergström"
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 setting up some LAPACK test
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
oth issues with explanations as to why.
- Chuck
From 4c33d91f999b9030b4666be2f94d7a86c8da8527 Mon Sep 17 00:00:00 2001
From: Chuck Atkins
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 static
arra
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, th
oo to be found instead.
Patch attached
- Chuck
From cfc0008206155c5244c205c3f77bba911c109b6c Mon Sep 17 00:00:00 2001
From: Chuck Atkins
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
Yep. That fixed it. Thanks!
Chuck Atkins
R&D Engineer, Kitware, Inc.
-- "Mathematicians are tools for turning coffee grounds into formulas.",
Paul Erdos
2012/3/14 Nicolas Desprès
> Try with this branch:
> https://github.com/polrop/ninja/tree/depfile-parser-accept-
Just to clarify with more information:
cmake: d2d492f492a8a6082345e439a9c15418f0d483db
- This is the head of the branch that was merged into next
ninja: fdec96f54e92d2990ebf1ba5434b317d3d8ad49d
- Tues, Mar. 13
Chuck Atkins
R&D Engineer, Kitware, Inc.
(518) 371-3971 x603
chuck.atk...@kitware
t be that the odd-ball characters in the filenames are
breaking some regex somewhere? Not sureif the issue would be in ninja
itself or in the cmake-ninja integration.
Thanks
Chuck Atkins
R&D Engineer, Kitware, Inc.
-- "Mathematicians are tools for turning coffee grounds into formu
78 matches
Mail list logo
