Hi Sanu,
We test pgi pretty heavily so it should work okay. Can you show the output
failure you get when trying to configure?
- Chuck
On Tue, Jul 23, 2019, 1:21 AM 李 三乎 wrote:
> Dear CMake Community,
>
> I’m here to report an error occurred when using PGI compiler. The readme
> for CMake asks
So, a couple things:
string(TOUPPER ${lib} lib_upper)
> set(WITH_LIB_${lib_upper}_EXAMPLES "")
>
> This needs to be outside the foreach loop. It's getting reset to empty on
every iteration rather than accumulating results
list(APPEND
Hi John,
Two different compilers in the same project for the same language is messy,
but in your case it's directly supproted as a special case for cuda using
the CMAKE_CUDA_HOST_COMPILER CMake variable or the CUDAHOSTCXX environment
variable.
--
Chuck Atkins
Staff R Engineer, Scientific
ARIES)
if(NOT HAVE_LIBM_MATH)
message(FATAL_ERROR "Unable to use C math library functions")
endif()
set(LIBM_LIBRARIES m)
endif()
target_link_libraries(fooTarget PRIVATE ${LIBM_LIBRARIES})
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri,
>
> When I ran "cmake .." in bin, cmake complained that it could not find
> source file src1.h in add_executable. What is wrong here?
>
Hi Lei,
Alex hit several of these points, but to wrap it up together:
A couple of things...
- There's no need for a CMakeLists.txt in a directory if it's
Hi Frank,
What version of CMake are you running (cmake --version) and what is are you
running on? Is this on the Windows Subsystem for Linux? Older CMake
versions had similar trouble there that was resolved with more recent
releases.
- Chuck
On Thu, Oct 18, 2018, 17:04 Jean-Christophe
Hi Rob,
How would one set a variable containing multiple definitions to be passed
> to target_compile_definitions() ?
>
The example you gave works (adjusting for typos, PIC, and adding visibility
specifier):
...
set(COMMON_DEFINITIONS SOME_DEFINE_1 SOME_DEFINE_2 SOME_DEFINE_3)
...
- Chuck
>
> *From: *Chuck Atkins
> *Date: *Thursday, October 11, 2018 at 2:55 PM
> *To: *Rob Boehne
> *Cc: *CMake Mail List
> *Subject: *Re: [CMake] Building arguments to target_comple_definitions()
>
>
>
> So, are you suggesting that I make a “dummy” targe
>
> So, are you suggesting that I make a “dummy” target and fill it with the
> common options in compile_definitions() and include_directories() (et. al.)
>
> Then make my OBJECT libraries (and the shared library) depend on the
> “dummy” target?
>
>
> If that’s not the suggestion, I’m afraid I
> COMMAND "${GIT_EXECUTABLE}" describe --always HEAD
>
git describe is nice way to do it since you can get a monotonic-ish
increasing version number
>
> string(REGEX REPLACE "^.*-(.*)-g.*$" "\\1" MYAPP_VERSION_MICRO
> "${MYAPP_VERSION}")
> ...
> set(MYAPP_VERSION_MICRO "0")
>
Only
Hi Rob,
> target_compile_definitions( CHUNK1 ${COMMON_DEFINITIONS} CHUNK1_STUFF
> CHUNK_NAME=\”One\” )
>
> target_compile_definitions( CHUNK2 ${COMMON_DEFINITIONS} CHUNK2_STUFF
> CHUNK_NAME=\”Two\”)
>
> target_compile_definitions( FooBar ${COMMON_DEFINITIONS} )
>
This is what I was referring
Hi Burlen
Of course I read the documentation.
>
I certainly didn't mean for that to come off as an "rtfm", so my appologies
if it did, that wasn't my intent.
> why did they MPI_C_LIBRARIES and MPI_C_INCLUDE_DIRS/PATH get changed from
> cache variables to not chached variables? that seems to
or determine the MPI
installation? If that's the case then we should probably fix that issue
instead.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
(518) 881-1183
On Thu, Sep 13, 2018 at 4:46 PM Burlen Loring
wrote:
> Hi,
>
> I'm trying to transition from cm
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
Hi Chris.
Try using the the CMAKE_CXX${std}_STANDARD_COMPILE_OPTION variable. For
example, the folowing piece of CMake code:
cmake_minimum_required(VERSION 3.9)
project(foo CXX)
foreach(std IN ITEMS 98 11 14 17)
message("C++${std} std flags: ${CMAKE_CXX${std}_STANDARD_COMPILE_OPTION}")
CMAKE_PREFIX_PATH just adds a set of search paths. To instead have it
shift it's entire search infrastructure, you can use the
CMAKE_FIND_ROOT_PATH CMake variable and a few associated with it, which
will cause the entire set of search heuristics to be re-rooted in the
specified path. First run
printf("Library foo uses file %s\n", filename);
return 0;
}
This will give you "libfoo.so" on Linux, "libfoo.dylib" on Apple, and "
foo.dll" on Windows.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Tue, Jan 9, 2018
Hi Nathan,
I am able to reproduce this error on our Dashboard machine; it should be
working and clearly it's not at the moment.
I will investigate...
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Tue, Dec 19, 2017 at 11:48 AM, Nathan Strong <gblues
Hi Jupiter,
Compiling the C compiler identification source file "CMakeCCompilerId.c"
> failed.
> Compiler: /usr/local/gcc/4.9.1/bin/gcc
> Build flags: /usr/local/cppcms/1.1.0/include
>
It looks like you have an errant "/usr/local/cppcms/1.1.0/include" set in
your CFLAGS environment variable, or
>
> cause cpack does not "rebuild" the software again, it uses the compiled
> software and just starts the "install" into its _CPack_Packages
> subdirectories
>
Just running `cpack` does not. However, CMake does generate a "package"
make target that is tied into your dependencies, so if instead
> > In calls to cpack only one core is used if Makefiles are used. Is there
> any option to enable multicore?
>
It depends on what your trying to achieve. Typically the bottleneck for
CPack is in the compression step of the resulting tar (or rpm, etc.). In
that case, CMake is limited by the
Hi David,
> Supporting OBJECT libraries in
> target_link_libraries calls was mentioned mentioned right back here
> https://cmake.org/pipermail/cmake-developers/2012-March/015422.html but
> sadly seems still to be on the back burner.
>
It's not on the back burner! There has been progress on
.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri, Jun 30, 2017 at 1:17 PM, Rajesh Kumar <thisiz...@gmail.com> wrote:
> Tried with cmake 3.8.2 version. Able to compile CMOCKA.
>
> Regards
> Rajesh
>
> On Wed, Jun 21, 2017, 3:10 PM Rajesh Kumar <
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
Hi Rajesh,
We would need more information to be useful:
- What version of CMake are you using?
- What compiler and version are you using?
- What OS and version are you using?
- Do you have separate source and build directories?
- How are you running cmake?
--
Chuck
Hi Petros,
This doesn't really answer your question but it may solve your problem a
different way. I've fought this very same boost problem many times in the
past. In my case it was needing to link against Matlab dev libraries,
which in turn pulled their own private copy of boost in. I tried a
and C++ compilers are
detected as Clang then I suspect it's rather old. They should also be
detected as XL like the Fortran compiler. Do you get the same XL Fortran
errors using a new version of CMake?
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
--
Powered by www.kitwar
(bar1
bar2
)
All of which have their justifications.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri, Jun 2, 2017 at 1:57 AM, Frank Roland <theldo...@hotmail.com> wrote:
> There is probably a faulty indentation implemented in cmake-mode
>
> 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.
-- 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
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
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
expected.
------
Chuck Atkins
Staff R 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
Kitware offers various services to support the CMake community. For more
informatio
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
>
> I'll try and see if I can compile a gcc 4.9.3 chain on the CentOS 5
> machine (I need C++11).
>
I'd suggest using the devtollset repo from
https://people.centos.org/tru/devtools/devtools.repo
> The docker container looks interesting but I haven't used it yet: does it
> need some specific
If you're using a newer Ubuntu environment, I'd suggest using a CentOS 5
docker container. Either that or the VM.
- Chuck
On Tue, Mar 7, 2017 at 1:53 PM, Marcel Loose wrote:
> Hi Michele,
>
> This could become a painful exercise. You basically have two options:
> 1) Treat it
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
you should need to do is source the setup script as I described here:
source /opt/intel/bin/compilervars.sh intel64
>
That should place the compilers in the search path for your current shell.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
--
P
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
Hi YC,
> cmake version on fedora 25: 3.6.2
>
Fedora is specifically patching CMake in the RPM spec file to reduce the
gcc flag from O3 to O2 so it's the distributuion's packaging making that
change, not CMake itself. If you download and build the source from
cmake.org then you'll get O3 as
Hi Adrian,
I'd suggest taking the issue up with the package maintainer. The upstream
source for CMake 3.7.2 configures, builds, and passes all tests on EL7 so
the problem seems to lie in how the RPM SPEC file is driving the build.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
l) = 247.03 sec
[chuck.atkins@deepthought v3.7.2]$
What specific versionof EL7 are you running and which version of GCC?
------
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www
FWIW, we've moved to CentOS 6 for the binaries we package and distribute
for ParaView. It's about the oldest widely deployed Linux distro that's
still actively supported (EL5 is EOL'd and most deployments have long since
moved to 6 or 7). it's binaries are compatible with virtually all current
.:
add_library(lib1-obj OBJECT $(CMAKE_CURRENT_SOURCE_DIR}/lib1.cpp).
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri, Dec 9, 2016 at 5:26 AM, Giovanni Funchal <g...@cloudnc.co.uk> wrote:
> Hi,
>
> Apologies, the problem wasn't properly minimise
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
>
> The library linking against "originalLibraryForward" has to be
> compiled from the original sources too. Actually performing the
linking step should be sufficient. Is there a way to accomplish that?
>
Object libraries are what you need here. See
> why does it not interrogate the MPI wrapper if set as FC or CC?
>
CC, CXX, and FC env vars are just used to initialize the
CMAKE_{C,CXX,Fortran}_COMPILER variables wihch CMake will then use as the
"regular" compilers for a given language. If those regular compilers
already work with MPI then
>
> As far as enhancements to FindMPI go, It might be worthwhile to check if
> FC, CC,CXX match any obvious MPI wrappers, and then set MPI__compiler
> and select the MPI version from there: If the user set the compiler
> explicitly to an MPI wrapper, that's likely the MPI they intend to use
>
Hi Zaak,
Sorry for the first mail being so abrupt, I didn't mean to hit "send" so
soon.
> I took a look at the FindMPI CMake module, and it seems as though you can
> set MPI_HOME to a list of directories to search.
>
That's also another way of doing it, which would probably be easier than
the
MPI wrappers. FindMPI will then interrogate the MPI wrappers to extract
the appropriate include and link options.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Mon, Nov 28, 2016 at 9:58 AM, Chuck Atkins <chuck.atk...@kitware.com>
wrote:
> Pass the
Pass the following CMake options at configure time:
-DMPI_C_COMPILER=/path/to/mpicc
-DMPI_CXX_COMPILER=/path/to/mpiCC
-DMPI_Fortran_COMPILER=/path/to/mpif90
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Wed, Nov 23, 2016 at 6:05 PM, Zaak Beekman <zb
++
Makefile processor on this system is: gmake
g++ is GNU compiler
g++ has setenv
g++ has unsetenv
g++ does not have environ in stdlib.h
g++ has stl wstring
-
... lots of compile output ...
loading initial cache file /home/khq.kitware.com/chuck.
atkins/Code/CMake
. The default
configuration of the ./bootstrap command should be using internal versions
of all of CMake's dependencies. Is that causing problems for you?
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Wed, Nov 2, 2016 at 1:08 PM, Jayesh Badwaik <pub...@jayeshbadwaik
that's exactly what you've done. Just
confirming that yes that's a sane approach and that's how we do it to.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Mon, Oct 10, 2016 at 9:56 AM, Robert Bielik <robert.bie...@dirac.com>
wrote:
> For referenc
ns in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f90c7ba54f1a9a61e930292207d3387df40b2dad
commit f90c7ba54f1a9a61e930292207d3387df40b2dad
Merge: c8a4533 495f924
Author: Chuck Atkins <chuck.atk..
>
> 1. Toolchain needs to be in a separate file
>
Yes, that is certainly best practice and makes the rest of the
cross-compiling infrastructure just work better.
> 2. That file needs to be called before the project line of your
> CMakeLists.txt
>
You actually shouldn't be "calling" it at
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
configuring
your build, try adding -DCURSES_NCURSES_LIBRARY=IGNORE to prevent
FindCurses from picking the wrong one.
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.
On Fri, Aug 19, 2016 at 5:14 AM, Zeson Wu <westion...@gmail.com> wrote:
> /usr/bin/g++-Wl,-bno
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9477b66889974bf27c435ef951435a557bfd1b7
commit c9477b66889974bf27c435ef951435a557bfd1b7
Merge: d8a2506 55e7287
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 9 08:01:14 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d8a2506da003e45b84c1f8e09960b60037be7434
commit d8a2506da003e45b84c1f8e09960b60037be7434
Merge: d20a973 970eaed
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 9 08:00:11 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e52f1401237c7aa646ca6ecbe7f1eb78b018607f
commit e52f1401237c7aa646ca6ecbe7f1eb78b018607f
Merge: 20b89cd 37507ff
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Aug 8 11:03:11 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=20b89cd9be9f35c547e4cebc1fbbda251cad954b
commit 20b89cd9be9f35c547e4cebc1fbbda251cad954b
Merge: 717ece1 dd46b95
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Aug 8 11:02:14 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=717ece197f2931fe9d633b0fe1074aa3416eed0c
commit 717ece197f2931fe9d633b0fe1074aa3416eed0c
Merge: 4a5e3be 8872cd1
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Aug 8 10:48:00 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=05c29d64b440766b28622db87d5ab91069ec2af7
commit 05c29d64b440766b28622db87d5ab91069ec2af7
Merge: f4cc3c3 e52302d
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 09:02:49 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f4cc3c36d7a704951d87abfd3031182871aa0d41
commit f4cc3c36d7a704951d87abfd3031182871aa0d41
Merge: 721ea79 7e29fda
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Fri Aug 5 09:00:54 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6773d23c4ca2cf59726734aba131f2be36307f0
commit f6773d23c4ca2cf59726734aba131f2be36307f0
Merge: a67e5b8 3881470
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Aug 4 15:26:52 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=dc1dbedc733126da4ed0fff03cefab71b0692d22
commit dc1dbedc733126da4ed0fff03cefab71b0692d22
Merge: e6bfb7d 8eb0b56
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Aug 2 10:42:08 2016 -0400
Commit:
Hi Yaron,
I think it should b renamed to "LIBXML2_COMPILE_FLAGS".
>
Xxx_DEFINITIONS is one of the standard variable names for a given
FindXxx.cmake find module, see
https://cmake.org/cmake/help/v3.6/manual/cmake-developer.7.html#standard-variable-names
.
> If u wish, I can submit a patch.
>
Hi Lev,
However, the target builds only if I explicitly say 'make foo_sqlite'. So
> far
> so good. Is there any way I can make it build if I just say 'make'?
>
See the add_custom_target documentation for the ALL option,
https://cmake.org/cmake/help/v3.6/command/add_custom_target.html
And,
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a135841da3110538f92f9aa51923e51157f31f1b
commit a135841da3110538f92f9aa51923e51157f31f1b
Merge: 67849b9 412f76c
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Jul 28 12:10:57 2016 -0400
Commit:
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67849b913481d1e686742d8e543d0dc97495553e
commit 67849b913481d1e686742d8e543d0dc97495553e
Merge: 10aeccb fe54ce5
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu Jul 28 12:10:11 2016 -0400
Commit:
df66730c48
commit e752540b9f56d82cc5527c681c3883df66730c48
Merge: 858f96e 9e301f7
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Wed Jul 27 10:32:59 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Wed Jul 27 10:32:59 2016 -0400
Merge topic 'a
Hi Brennan,
We also just got the Homebrew cmake formula updated to explicitly include
the patch. See https://github.com/Homebrew/homebrew-core/pull/2968
- Chuck
On Wed, Jul 13, 2016 at 11:10 PM, Breannan Smith
wrote:
> Rad, I can verify that the issue is resolved in
>
> Thanks for your analysis for me Andrew. I can't use "-j" options, i think
> the
reason is the project i dealed with is not parallel. Thus when i use "make
> -jN", it couldn't work correctly every time. Obviously it caused by the
> Makefile generated by CMake, so i wonder if there are some
e: 0d7f858 d5e4516
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Jul 12 15:55:06 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Jul 12 15:55:06 2016 -0400
Merge topic 'fix-misc-hdf5-issues' into next
d5e4516e FindHDF5: Cl
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=230ad0d96f390c5e4b300f4cb3103e341556f542
commit 230ad0d96f390c5e4b300f4cb3103e341556f542
Merge: cfdb159 7f3c28a
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jul 11 12:06:04 2016 -0400
Commit:
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
You could try to force libxml to be ignored by CMake so it will think it
wasn't found and use the fallback configuration:
cmake ... -DLIBXML2_LIBRARIES=IGNORE ...
- Chuck
On Tue, Jun 14, 2016 at 8:28 PM, Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:
> Building llvm/clang from source
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6efb9214e46763a2a731938e3948fc8751f51167
commit 6efb9214e46763a2a731938e3948fc8751f51167
Merge: 68b0ed4 90d114e
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue Jun 14 09:56:45 2016 -0400
Commit:
Hi Cedric,
It sounds like creating a package config file is exactly what you need.
When installed, a user will be able to consume your project with
"find_package(Foo)". That will locate and read the package config file
which will create an imported target Foo::Foo. This imported target will
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fba0b6b15f0528bf88da45b3fdaca304552bd255
commit fba0b6b15f0528bf88da45b3fdaca304552bd255
Merge: 1e49316 25aa576
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon Jun 13 10:21:41 2016 -0400
Commit:
ns in full, below.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0d3c95e99e875c846381c472e6e1f066d42eb019
commit 0d3c95e99e875c846381c472e6e1f066d42eb019
Merge: 63bc1a8 5537355
Author: Chuck Atkins <chuck.atk..
eated by all the different projects (I have actually
> already seen this a lot). That is the case, because the FindFooBar.cmake
> file is not provided by the FooBar project, unlike the FooBarConfig.cmake.
>
> Cheers,
> Sven
>
>
> On 06/08/2016 03:11 PM, Chuck Atkins wrote:
>
> T
I was able to verify, btw, that Fedora 19 + Power8 outputs ppc64le for
uname -m so I assume it works correctly on EL7 as well. Testead via an IBM
machine hosted at the OSU Open Source Lab that we can access and use for
testing.
- Chuck
On Wed, Jun 8, 2016 at 10:33 AM, M Kelly
The FooBarConfig.cmake is something that should be generated by FooBar's
build. The reason you don't get absolute paths for the "libraries" from a
package config file is that they're not actually libraries but imported
targets. The imported target let's you treat "foo" as though it were a
Could you just make the tests run in the post-build of the test?
add_library(Foo Foo.cxx)
add_executable(FooTest FooTest.cxx)
target_link_libraries(FooTest Foo)
add_custom_command(TARGET FooTest POST_BUILD
COMMAND $ $
)
That way the the test is run as part of it's build.
- Chuck
On Wed,
;
> Version:
>
>
>
> [eschnigma@manjaro ~]$ g++ --version
> g++ (GCC) 6.1.1 20160501
> Copyright (C) 2016 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PAR
>
>[eschnigma@manjaro build]$ cmake .. -DCMAKE_BUILD_TYPE:STRING="Debug"
> -- The C compiler identification is unknown
> -- The CXX compiler identification is unknown
>
This is definitely the reason for no debug symbols. If the compiler is
unknown then CMake won't know the right flags to
Hi Chao,
You want to let CMake to as much of the work for you as possible. You're
still trying to explicitly pass the path to the library file to
target_link_libraries. If you look at the line:
target_link_library(exe1 "-Wl, --whole-archive ../sub_dir1/liblib1.a
--no-whole-archive")
there's
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=eec9b0f91dac9ac4dc938c624b44ac55b69b3c1c
commit eec9b0f91dac9ac4dc938c624b44ac55b69b3c1c
Merge: 43d02bf b63eb05
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Tue May 24 10:42:28 2016 -0400
Commit:
AM, Chaos Zhang <zcsd2...@gmail.com> wrote:
> Thanks a lot! `set(FOO_LIBRARY "-Wl,--whole-archive ${FOO_LIBRARY}
> -Wl,--no-whole-archive")` worked when the content of ${FOO_LIBRARY} look
> like `-Ldir -llib`, if just use lib name as the content of ${FOO_LIBRARY},
>
> -rpath
RPATHs are automatically added by CMake to executables so they can use
libraries from the build tree.
> -whole-archive
>
whole-archive is definitely trickier since you shouldn't be applying it to
the entire executable but instead wrapping individual libraries with it.
Conveniently,
Is there a reason to not use target_link_libraries here? For the purposes
of your example there's no reason to be using CMAKE_EXE_LINKER_FLAGS. What
are you actually trying to accomplish? Because there is almost certainly a
better way to achieve your desired result than via
> when I place set(CMAKE_SYSTEM_NAME Generic) after cmake_minimum_required()
> and project() and set(VERSION_MAYOR/MINOR),
>
CMAKE_SYSTEM_NAME really shouldn't be in a CMakeLists.txt file at all. It
should instead be in a stand alone toolchain file defining your various
cross-compiling
Hi TCW,
A typical approach for this is in the top level CMakeLists.txt to have:
include(CompilerFlags)
And then you can isolate the detection and specialization logic in a
separate CompilerFlags.cmake:
if(CMAKE_COMPILER_IS_GNUC)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS" -extra --gcc-options")
>
> 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
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=969ac90d3805db87e32929de3305d1af5470aba6
commit 969ac90d3805db87e32929de3305d1af5470aba6
Merge: af395dc fdfb0c0
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Thu May 12 13:56:30 2016 -0400
Commit:
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
-
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
-
ow.
- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1ea20a5782ac72f5d4616360d73e51cf3958dd2
commit d1ea20a5782ac72f5d4616360d73e51cf3958dd2
Merge: 943d8b4 00405af
Author: Chuck Atkins <chuck.atk...@kitware.com>
AuthorDate: Mon May 9 10:21:59 2016 -0400
Commit:
1 - 100 of 275 matches
Mail list logo