[CMake] Cannot generate a safe runtime search path with mex and matlab
I am running into an error "Cannot generate a sage runtime search path for target because files in some directories may conflict with libraries in implicit directories." I understand from the error message why this is happening, but I'm not certain how to get around it. In my CMakeLists.txt file, I have: matlab_add_mex(NAME SRC .c LINK_TO foo baz) and the problem is that foo is a shared lib that links to the HDF5 library. However, matlab is bundled with its own copy of the HDF5 library, in a path automatically added by FindMatlab.cmake. Foo and baz are built elsewhere, and are imported using the config variant of find_package(). How can I get around this issue? Thanks, --Jack -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] make install gives cmake link errors for libstdc++
I'm having an odd problem. I built and installed cmake in a non-standard location, using a compiler different from the system compiler on linux. Cmake compiles without complaint, and installs without complaint. When I attempt to build a piece of software using cmake, the configuration and build stages are fine. However, when I run 'make install', I get errors similar to: /my/version/cmake: /usr/lib64/libstdc++.so.6: version 'GLIBCXX_3.4.20' not found (required by cmake) The funny thing is, though /my/version/cmake is not linked to /usr/lib64/libstdc++.so.6. Instead, it's linked to /my/version/libstdc++.so.6, as I intended. I've verified this with ldd, which only shows the latter expected results. /my/version/libstdc++.so.6 is in the library path, too, Not sure what's going on. Can someone help? --Jack -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] Visual Studios platform choice
Hi, I understand from reading this newgroup (e.g. https://cmake.org/pipermail/cmake/2013-March/053775.html) that the only way to support multiple platforms in Visual Studio is to run CMake multiple times, once for each platform. I'm porting some linux based code to the Windows world, and the Windows dev showed me that in Visual Studio, platform choice is a pulldown menu at the top of the screen. This pulldown appears even if we run CMake without specifying a 64 bit platform. This is a bit confusing, because we've only generated a solution and project file for 32 bit. So what happens when someone selects 64 bit on the pulldown menu? What's being built? Thanks -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] visual studio tries to link to non-existent static version of lib
The following works on Linux, for both GNU and Intel compilers:
add_library(mylib SHARED ${mylib_sources})
target_link_libraries(mylib ${mylib_libraries})
...
add_executable(test_mylib test_mylib.c)
target_link_libraries(test_mylib mylib ${test_mylib_libraries})
add_test (TestMylib test_mylib)
However on windows, using Visual Studio, building test_mylib fails with the
message "cannot open file Debug\mylib.lib". But I have not asked for a
static library, and I'm not sure why VS is trying to link to it. Is there
some extra step I need to take to make this work on Windows?
--Jack
--
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
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] FindMPI prefer mpirun over mpiexec
Hi, Is there a way to make FindMPI prefer the name 'mpirun' over 'mpiexec'? They have different meanings to Intel's MPI. By default, FindMPI locates mpiexec, which runs the MPD based MPI. I'd rather use mpirun. FindMPI knows mpirun, but in FindMPI.cmake, it looks like mpirun is searched after mpiexec. Is there a simple solution for this? --Jack -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] FindMPI uses wrong fortran include path
Hi,
If I call FindMPI, it successfully finds Intel MPI, including all the
proper include paths etc. However, when I compile MPI code, I get an error
message saying that the mod file (called by "use mpi" in the code) was not
compiled by this compiler. The problem appears to be that the Intel
compiler suite installed both gfortran and ifort versions of the mod files
in different include directories like this:
INTELROOT/
linux/mpi/intel64/include/gfortran/mpi.mod
linux/mpi/intel64/include/mpi.mod
where the first mod is the gfortran mod, and the second is the intel mod.
Following the call to FindMPI(), the variable MPI_Fortran_INCLUDE_PATH
contains both, with the gfortran directory first. If I do this:
include_directories(${MPI_Fortran_INCLUDE_PATH})
I get the failure I mentioned, presumably because the compiler tries to use
the gfortran mod first.
So is there a way to tell the build system to ignore the gfortran mod? I
cannot assume that the order or contents of MPI_Fortran_INCLUDE_PATH.
Thanks
--
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
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] FindMPI uses wrong fortran include path
This seems to be the same issue discussed here:
https://cmake.org/pipermail/cmake-developers/2014-December/023831.html
which refers to a bug marked fixed here:
http://www.cmake.org/Bug/view.php?id=15182
However, I'm still getting the issue in 3.5.0-rc1
On Wed, Feb 10, 2016 at 12:24 PM, Jack Stalnaker <omnij...@gmail.com> wrote:
> Hi,
>
> If I call FindMPI, it successfully finds Intel MPI, including all the
> proper include paths etc. However, when I compile MPI code, I get an error
> message saying that the mod file (called by "use mpi" in the code) was not
> compiled by this compiler. The problem appears to be that the Intel
> compiler suite installed both gfortran and ifort versions of the mod files
> in different include directories like this:
>
> INTELROOT/
> linux/mpi/intel64/include/gfortran/mpi.mod
> linux/mpi/intel64/include/mpi.mod
>
> where the first mod is the gfortran mod, and the second is the intel mod.
> Following the call to FindMPI(), the variable MPI_Fortran_INCLUDE_PATH
> contains both, with the gfortran directory first. If I do this:
>
> include_directories(${MPI_Fortran_INCLUDE_PATH})
>
> I get the failure I mentioned, presumably because the compiler tries to
> use the gfortran mod first.
>
> So is there a way to tell the build system to ignore the gfortran mod? I
> cannot assume that the order or contents of MPI_Fortran_INCLUDE_PATH.
>
> Thanks
>
--
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
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] ifort: command line remark #10148: option 'i_dynamic' not supported
Hi, I am using cmake 2.8.12.2, and I'm getting this warning when I attempt to link a fortran program or library. ifort: command line remark #10148: option 'i_dynamic' not supported I cannot find very much about this error searching the web. What does this mean? Thanks -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] exclude a dependency from export
Is there any way to exclude a dependency from an export? If I build a static library target "A" but do not wish to install it, and then link that target to another target "B" using target_link_libraries(B A), and then attempt to export B, I get the error message: install (EXPORT "B" ...) includes target "B" which requires target "A" that is not in the export set. I can solve the problem by installing A, but there is no need to. It is a temporary target that is statically linked. I just need to export for creating a package config file, so there's no need for the package config to ever need to worry about statically linked libraries. Is there a workaround for this? Long story short, I am trying to replicate convenience libraries from autotools. I'm having a hell of time doing it. I can use lists of sources, but that requires passing around global variables that include the sources and others that include the required libraries. This is far messier and far less convenient. I've tried object libraries, and while they eliminate the global source variables and prevent rebuilding things, they fail when the source is nested, and you want to build a "super library" from smaller object libraries, which I believe is a fairly common working pattern. Building a static library that is never installed works really well ... until I go to create a package config file. Then this export fails. Thanks, --Jack -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] exclude a dependency from export
Private doesn't work because the names in A need to be part of the public interface. On Fri, Jan 22, 2016 at 11:51 AM, Nicholas Braden < nicholas11bra...@gmail.com> wrote: > Have you tried using the PRIVATE keyword when linking to A? > > https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents > > On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <omnij...@gmail.com> > wrote: > > Is there any way to exclude a dependency from an export? If I build a > static > > library target "A" but do not wish to install it, and then link that > target > > to another target "B" using target_link_libraries(B A), and then attempt > to > > export B, I get the error message: > > > > install (EXPORT "B" ...) includes target "B" which requires target "A" > that > > is not in the export set. > > > > I can solve the problem by installing A, but there is no need to. It is a > > temporary target that is statically linked. I just need to export for > > creating a package config file, so there's no need for the package > config to > > ever need to worry about statically linked libraries. > > > > Is there a workaround for this? > > > > Long story short, I am trying to replicate convenience libraries from > > autotools. I'm having a hell of time doing it. I can use lists of > sources, > > but that requires passing around global variables that include the > sources > > and others that include the required libraries. This is far messier and > far > > less convenient. I've tried object libraries, and while they eliminate > the > > global source variables and prevent rebuilding things, they fail when the > > source is nested, and you want to build a "super library" from smaller > > object libraries, which I believe is a fairly common working pattern. > > Building a static library that is never installed works really well ... > > until I go to create a package config file. Then this export fails. > > > > Thanks, > > --Jack > > > > -- > > > > 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 > > information on each offering, please visit: > > > > CMake Support: http://cmake.org/cmake/help/support.html > > CMake Consulting: http://cmake.org/cmake/help/consulting.html > > CMake Training Courses: http://cmake.org/cmake/help/training.html > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/cmake > -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] exclude a dependency from export
I've found several workarounds, though I'm not sure of the long term ramifications. 1. I can "install" library A to CMAKE_CURRENT_BINARY_DIR effectively doing nothing. Since A is never referenced, only consumed, this should be okay? 2. I can remove the export from both A's and B's install, and simply not include the target.cmake file in my package config prototype. I can just include my targets as variables the same way a FindXXX.cmake file does. Makes the syntax slightly uglier in that you cannot refer to B by target name. It also might break the expectations of a user who thinks a package should include target names. I've started several discussions here on convenience libraries, and I think I'm starting to realize the Cmake team has a different definition than I do. To me, a convenience lib is not just an archived collection of sources. The convenience lib is already linked to any external libs and already was compiled with any special flags--in essence it's fully cooked. The nice thing about this is that it keeps all the details specific to that part of the code confined to that code's place on disc and that part of the code's CMakeLists.txt. Object libraries and source list variables require that other information to be passed around as well, leaking the convenience lib's requirements all over the code tree. You could argue that that means A should be a plain old library, then, but installing it serves no purpose. It will like never be referenced outside of the code tree, and it pollutes the system library folder. On Fri, Jan 22, 2016 at 1:20 PM, Jack Stalnaker <jack.stalna...@gmail.com> wrote: > Private doesn't work because the names in A need to be part of the public > interface. > > On Fri, Jan 22, 2016 at 11:51 AM, Nicholas Braden < > nicholas11bra...@gmail.com> wrote: > >> Have you tried using the PRIVATE keyword when linking to A? >> >> https://cmake.org/cmake/help/latest/command/target_link_libraries.html#libraries-for-a-target-and-or-its-dependents >> >> On Fri, Jan 22, 2016 at 9:14 AM, Jack Stalnaker <omnij...@gmail.com> >> wrote: >> > Is there any way to exclude a dependency from an export? If I build a >> static >> > library target "A" but do not wish to install it, and then link that >> target >> > to another target "B" using target_link_libraries(B A), and then >> attempt to >> > export B, I get the error message: >> > >> > install (EXPORT "B" ...) includes target "B" which requires target "A" >> that >> > is not in the export set. >> > >> > I can solve the problem by installing A, but there is no need to. It is >> a >> > temporary target that is statically linked. I just need to export for >> > creating a package config file, so there's no need for the package >> config to >> > ever need to worry about statically linked libraries. >> > >> > Is there a workaround for this? >> > >> > Long story short, I am trying to replicate convenience libraries from >> > autotools. I'm having a hell of time doing it. I can use lists of >> sources, >> > but that requires passing around global variables that include the >> sources >> > and others that include the required libraries. This is far messier and >> far >> > less convenient. I've tried object libraries, and while they eliminate >> the >> > global source variables and prevent rebuilding things, they fail when >> the >> > source is nested, and you want to build a "super library" from smaller >> > object libraries, which I believe is a fairly common working pattern. >> > Building a static library that is never installed works really well ... >> > until I go to create a package config file. Then this export fails. >> > >> > Thanks, >> > --Jack >> > >> > -- >> > >> > 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 >> > information on each offering, please visit: >> > >> > CMake Support: http://cmake.org/cmake/help/support.html >> > CMake Consulting: http://cmake.org/cmake/help/consulting.html >> > CMake Training Courses: http://cmake.org/cmake/help/training.html >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware
Re: [CMake] actually using cmake alternative to convenience libraries
In the real source code, baz is a thin wrapper for the foo/bar lib. It
combines them into a Python module library, and doesn't really contain any
substantial code of its own.
It's a convenience lib because in the real code, multiple executables and
libs are built from the source tree, and the stuff in lib is common to
most, if not all of these. I could make it a static lib, but it doesn't
need to be installed. I did initially get it working by simply not
installing the lib and setting a POSITION_INDEPENDENT_CODE property on the
static lib, but that didn't feel properly "cmake-ish". I'm trying to
recreate the FAQ's suggestion of simply listing the convenience lib sources.
As for the last suggestion, I was specifically trying to avoid listing the
sources in the top level CMakeLists.txt file. To me, that pollutes the
top-level file with stuff it shouldn't care about. In the likely event that
I have to change the contents of src or lib, I have to change the top-level
CMakeLists, which seems non-intuitive.
I realize all of this sounds incredibly pedantic, since I've found so many
workarounds by now, but I guess I'm trying to get to the bottom of the
CMake crew's vision of how what used to be convenience libs in autotools
should work in CMake. The idea of smashing together a set of common objects
and their dependencies into a convenient partially compiled/linked block
and passing it around without installing it just seems so, well, convenient
and clean, and I am trying to envision the alternative since otherwise
cmake seems so convenient and clean compared to autotools.
--Jack
On Wed, Nov 18, 2015 at 7:16 AM, Magnus Therning <mag...@therning.org>
wrote:
> On Tue, Nov 17, 2015 at 09:37:25AM -0600, Jack Stalnaker wrote:
> > I'm trying to figure out the best way to handle something that was a
> > convenience lib under autotools. I realize that there's a FAQ entry here:
> >
> >
> https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
> >
> > But its terse 2 paragraphs don't say how to actually do what it suggests.
> > My problem is this. I have this source tree:
> >
> > lib
> > |--foo.c
> > |--foo.h
> > |--bar.c
> > |--bar.h
> > |--baz.c
> > src
> > |--goo.c
> >
> > In lib, I need to somehow collectively refer to foo and bar. Okay, so I
> can
> > create a variable:
> >
> > set(foobarSRCS foo.c bar.c)
> > set(foobarLIBS ${externalLibFound})
> >
> > which is what the FAQ entry seems to suggest. However, this variable is
> not
> > visible to goo.c. Okay, so as an alternative, I can do this:
> >
> > set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc.
> >
> > but now the variable is not visible to baz.c, which also must include the
> > srcs to create a module library called _baz! I can of course do something
> > like this:
> >
> > set(foobarSRCSLOC foo.c bar.c)
> > set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE)
> >
> > but this feels dirty and repetitive.
> >
> > I also realize that I can just create the variables in src, but that kind
> > of defeats the entire purpose of walling of the common libs and their
> > dependencies in the first place.
> >
> > Is this the right way to work, or am I missing something simple?
>
> From your text above it sounds like foo.{c,h} and bar.{c,h} don't really
> belong together with baz.c (it's not part of the convenience lib). So,
> why not separate them?
>
> Another thought, you can always put a CMakeLists.txt in the parent dir
> to lib with
>
> set(foobarSRCS lib/foo.c lib/bar.c)
>
> (maybe with the use of CMAKE_CURRENT_SOURCE_DIR too).
>
> A final questin, why was it a convenience lib in the autotools setup?
> Unless there's really a need to compile the files multiple times the
> whole issue can be side stepped by making it a static lib.
>
> /M
>
> --
> Magnus Therning OpenPGP: 0xAB4DFBA4
> email: mag...@therning.org jabber: mag...@therning.org
> twitter: magthe http://therning.org/magnus
>
> As we enjoy great advantages from the inventions of others we should
> be glad of an opportunity to serve others by any invention of
> ours, and this we should do freely and generously.
> -- Benjamin Franklin
>
--
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
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] actually using cmake alternative to convenience libraries
I'm trying to figure out the best way to handle something that was a
convenience lib under autotools. I realize that there's a FAQ entry here:
https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
But its terse 2 paragraphs don't say how to actually do what it suggests.
My problem is this. I have this source tree:
lib
|--foo.c
|--foo.h
|--bar.c
|--bar.h
|--baz.c
src
|--goo.c
In lib, I need to somehow collectively refer to foo and bar. Okay, so I can
create a variable:
set(foobarSRCS foo.c bar.c)
set(foobarLIBS ${externalLibFound})
which is what the FAQ entry seems to suggest. However, this variable is not
visible to goo.c. Okay, so as an alternative, I can do this:
set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc.
but now the variable is not visible to baz.c, which also must include the
srcs to create a module library called _baz! I can of course do something
like this:
set(foobarSRCSLOC foo.c bar.c)
set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE)
but this feels dirty and repetitive.
I also realize that I can just create the variables in src, but that kind
of defeats the entire purpose of walling of the common libs and their
dependencies in the first place.
Is this the right way to work, or am I missing something simple?
--Jack
--
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
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] actually using cmake alternative to convenience libraries
I read about those, but they don't seem to provide a way to add linked in
libraries, so it didn't seem to add a lot over a list of sources. In
autotools, you could bind your convenience lib with any dependencies via a
LIBADD primary, and the added libs would automatically propagate to the
final target. This of course works in cmake if I build a real library, but
if I try to link a library (e.g. say the system math library) to the object
library, cmake tells me it cannot do that for object libraries. In that
case, it seems like I still need to create the foobarLIBRARIES variable to
provide to target_link_libraries later.
Am I missing something, or is there a way to somehow attach the necessary
external libraries to the object library as well?
Thanks,
--Jack
On Tue, Nov 17, 2015 at 11:14 AM, Bill Hoffman <bill.hoff...@kitware.com>
wrote:
> On 11/17/2015 10:37 AM, Jack Stalnaker wrote:
>
>> I'm trying to figure out the best way to handle something that was a
>> convenience lib under autotools. I realize that there's a FAQ entry here:
>>
>>
>> https://cmake.org/Wiki/CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F
>>
>> But its terse 2 paragraphs don't say how to actually do what it
>> suggests. My problem is this. I have this source tree:
>>
>> lib
>> |--foo.c
>> |--foo.h
>> |--bar.c
>> |--bar.h
>> |--baz.c
>> src
>> |--goo.c
>>
>> In lib, I need to somehow collectively refer to foo and bar. Okay, so I
>> can create a variable:
>>
>> set(foobarSRCS foo.c bar.c)
>> set(foobarLIBS ${externalLibFound})
>>
>> which is what the FAQ entry seems to suggest. However, this variable is
>> not visible to goo.c. Okay, so as an alternative, I can do this:
>>
>> set(foobarSRCS foo.c bar.c PARENT_SCOPE), etc.
>>
>> but now the variable is not visible to baz.c, which also must include
>> the srcs to create a module library called _baz! I can of course do
>> something like this:
>>
>> set(foobarSRCSLOC foo.c bar.c)
>> set(foobarSRCS ${foobarSRCSLOC} PARENT_SCOPE)
>>
>> but this feels dirty and repetitive.
>>
>> I also realize that I can just create the variables in src, but that
>> kind of defeats the entire purpose of walling of the common libs and
>> their dependencies in the first place.
>>
>> Is this the right way to work, or am I missing something simple?
>>
> There is a new feature to do that:
>
> https://cmake.org/Wiki/CMake/Tutorials/Object_Library
>
> --
> Bill Hoffman
> Kitware, Inc.
> 28 Corporate Drive
> Clifton Park, NY 12065
> bill.hoff...@kitware.com
> http://www.kitware.com
> 518 881-4905 (Direct)
> 518 371-3971 x105
> Fax (518) 371-4573
> --
>
> 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
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
--
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
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] CMP0022 not set
I'm getting a new warning from cmake version 2.8.12
Policy CMP0022 is not set: INTERFACE_LINK_LIBRARIES defines the link
interface. etc...
Target "xxx" has an INTERFACE_LINK_PROPERTIES property ...
I've not set this property anywhere explicitly. I'm getting the warning
from a target_link_libraries call where the library is a target defined in
the same CMakeLists.txt file. Why am I getting this warning?
Furthermore, if I set the cmake_policy as requested, I still get the same
warning, with the same message that the cmake_policy has not been set. I do:
cmake_policy (SET CMP0022 NEW)
cmake_policy (GET CMP0022 Foo)
message (STATUS "${Foo}")
The message shows that CMP0022 is NEW, yet I still get the message that its
undefiined. What am I doing wrong?
--Jack
--
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
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] detecting fortran c interface
Hi, I see that there is a built-in FortranCInterface module that provides a lot of useful information for calling Fortran from C and C++. However, is there a module that does the opposite? Specifically, I need to check that the Fortran compiler supports calling C routines. In our autoconf script we do this by test linking a program like so: AC_LINK_IFELSE(AC_LANG_PROGRAM([],[use iso_c_binding])], [action-if-yes],[action-if-no]) which just attempts to compile and link a one line program "use iso_c_binding". I know I can simply recreate this in cmake, but if there is a module that does it already, or if FortranCInterface does it already, I'd like to avoid reinventing the wheel. Is there something that does this? --Jack -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[CMake] check_fortrant_compiler_flag?
I see that there are standard modules for checking C and C++ compiler flags, but there is no equivalent for fortran. Gfortran and ifort, for instance, have different flags for changing/supporting source code format and line length restrictions, so it would be very useful to be able to check which of a list of flags works (if any). Is there a workaround, or is it easy to do myself? --Jack -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Fortran_FORMAT
I figured it out. My version of Cmake (2.8.2) does not have the Fortran_FORMAT property. Thanks! On Thu, Mar 13, 2014 at 1:15 PM, Nils Gladitz nilsglad...@gmail.com wrote: On 13.03.2014 17:40, Jack Stalnaker wrote: Can someone provide an example of Fortran_FORMAT in use? I cannot find anything other than a definition of the property online. Does one use I am not much of a Fortran person but: cmake_minimum_required(VERSION 2.8.12) project(Foo Fortran) add_executable(free free.f) set_target_properties(free PROPERTIES Fortran_FORMAT FREE) add_executable(fixed fixed.f) set_target_properties(fixed PROPERTIES Fortran_FORMAT FIXED) Produces the following compile command on my system (with the gnu Fortran compiler): /usr/bin/f95-ffixed-form -c /home/ngladitz/src/test/fortran/fixed.f -o CMakeFiles/fixed.dir/fixed.f.o /usr/bin/f95-ffree-form -c /home/ngladitz/src/test/fortran/free.f -o CMakeFiles/free.dir/free.f.o The respective -ffixed-form -ffree-form options are compiler specific. Which compiler are you using? Nils -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_CURRENT_LIST_DIR equivalent 2.8.2
I'm stuck at 2.8.2. Is there an equivalent or a workaround for CMAKE_CURRENT_LIST_DIR in this version? Thanks. -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Fortran_FORMAT
Can someone provide an example of Fortran_FORMAT in use? I cannot find anything other than a definition of the property online. Does one use set_target_properties(tgt PROPERTIES Fortran_FORMAT FREE) ? That doesn't seem to alter the compiler flags. -- 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 information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] check_function_exists failing for gcc built-in functions?
Hi, I'm having trouble with check_function_exists() when it comes to built-in functions in gcc. If I create just a simple C++ file with a call to sqrt() or pow() and have a CMakeLists.txt with the following lines, include (CheckFunctionExists) check_function_exists(sqrt HAVE_SQRT) cmake fails to find sqrt (or pow, log, exp, etc). In the sqrt case, CMakeError.log shows /usr/share/cmake/Modules/CheckFunctionExists.c:3: warning: conflicting types for built-in function 'sqrt' Linking C executable cmTryCompileExec /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec.dir/link.txt --verbose=1 /usr/bin/gcc -DCHECK_FUNCTION_EXISTS=sqrt -fPIC CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.c.o -o cmTryCompileExec -rdynamic CMakeFiles/cmTryCompileExec.dir/CheckFunctionExists.c.o: In function 'main': CheckFunctionExists.c:(.text+0x15): undefined reference to 'sqrt' What is the workaround for this, in the situation where the function is built in, but I want to test for it on other platforms? Thanks -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack source distribution recursing out of control
You're right. It was partly because I had my build tree as a subdirectory of my source tree. Just used to that from autotools. I also failed to ignore my .git directory, which also contributed to the slowness. With both fixed, the speed and tarball size are fine. Thanks On Tue, Sep 18, 2012 at 1:27 AM, Eric Noulard eric.noul...@gmail.comwrote: 2012/9/18 Jack Stalnaker jack.stalna...@gmail.com: Hi, I'm not sure what I'm doing wrong, but when I run cpack --config CPackSourceConfig.cmake -G TGZ, the operation runs forever and produces archives on the order of dozens of gigabytes. As far as cpack goes, I don't have much specified other than include(cpack) and the version variables. May be you could send us your CPackSourceConfig.cmake ? I do have include(InstallRequiredSystemLibraries) as well, but that's pretty much it. Which version of CPack are you using? On which platform (Windows? Linux? ...) I did some investigation, and the problem was pretty easy to spot. Inside the generated _CPack* directory was the installed source directory, which in turn had a nested copy of the same source directory, etc, down many, many levels, so that many gigabytes of disc space were consumed. I'm sorry if this isn't specific enough, but does anyone know what's going on? Is your build tree inside the source tree, i.e. the build directory is a sub-directory of the build tree? Do you set CPACK_SOURCE_IGNORE_FILES to any values in your CMakeLists.txt? Does the problem with other generator like zip ? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack source distribution recursing out of control
Hi, I'm not sure what I'm doing wrong, but when I run cpack --config CPackSourceConfig.cmake -G TGZ, the operation runs forever and produces archives on the order of dozens of gigabytes. As far as cpack goes, I don't have much specified other than include(cpack) and the version variables. I do have include(InstallRequiredSystemLibraries) as well, but that's pretty much it. I did some investigation, and the problem was pretty easy to spot. Inside the generated _CPack* directory was the installed source directory, which in turn had a nested copy of the same source directory, etc, down many, many levels, so that many gigabytes of disc space were consumed. I'm sorry if this isn't specific enough, but does anyone know what's going on? Thanks, --Jack -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack -C CPackSourceConfig.cmake not making source package
--config worked. Wow, if -C is the wrong option, I wish it wouldn't appear in the tutorial and in the wiki section on creating a package. From cmake.org itself. That's confusing. It's not the only error I've noticed in the tutorial. In the section on testing, it's never mentioned that enable_testing() has to be called. I only found that out when my tests failed to run. I had to search outside the tutorial for the appropriate sequence of calls, and then verify in the tutorial source files that enable_testing was called. I did try an out of source build (making certain to delete the cache files first), but I got the same results. It's still only packing the bin directory with the built file. Thanks for the help. On Fri, Sep 7, 2012 at 11:52 AM, Eric Noulard eric.noul...@gmail.comwrote: 2012/9/7 Jack Stalnaker jack.stalna...@gmail.com: Even if I download the tutorial sources directly from cmake.org (for this tutorial http://www.cmake.org/cmake/help/cmake_tutorial.html ), unzip them, and run cpack -C CPackSourceConfig.cmake, I don't get a source package. -C is the wrong option. You should do: cpack --config CPackSourceConfig.cmake I get what I would consider a binary package. I saw that another user had reported the same issue here http://cmake.3232098.n2.nabble.com/How-to-deliver-a-source-code-package-td6505888.html but didn't really resolve it. That user resorted to make package_source, which does indeed pack up the source...and everything else in the directory. This is the expected CPack source packaging behavior. If you want to avoid that: 1) build out-of-source: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees 2) setup appropriate value for CPACK_SOURCE_IGNORE_FILES see cpack --help-variable CPACK_SOURCE_IGNORE_FILES I tried throwing some dummy sandbox files in there, and they get zipped right up, too. Am I doing something wrong? I'm following the tutorial as well as I can tell. It seems like the command above should create a source package containing no binary files, and only the sources that you have told it to include. CPack source packaging is currently packaging the source directory while excluding CPACK_SOURCE_IGNORE_FILES that's unfortunately a very basic behavior. CPack cannot tel apart binary or source file unless you do out-of-source build. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cpack -C CPackSourceConfig.cmake not making source package
Ignore the last paragraph of my previous message. That was with the '-C' option. On Fri, Sep 7, 2012 at 12:10 PM, Jack Stalnaker jack.stalna...@gmail.comwrote: --config worked. Wow, if -C is the wrong option, I wish it wouldn't appear in the tutorial and in the wiki section on creating a package. From cmake.org itself. That's confusing. It's not the only error I've noticed in the tutorial. In the section on testing, it's never mentioned that enable_testing() has to be called. I only found that out when my tests failed to run. I had to search outside the tutorial for the appropriate sequence of calls, and then verify in the tutorial source files that enable_testing was called. I did try an out of source build (making certain to delete the cache files first), but I got the same results. It's still only packing the bin directory with the built file. Thanks for the help. On Fri, Sep 7, 2012 at 11:52 AM, Eric Noulard eric.noul...@gmail.comwrote: 2012/9/7 Jack Stalnaker jack.stalna...@gmail.com: Even if I download the tutorial sources directly from cmake.org (for this tutorial http://www.cmake.org/cmake/help/cmake_tutorial.html ), unzip them, and run cpack -C CPackSourceConfig.cmake, I don't get a source package. -C is the wrong option. You should do: cpack --config CPackSourceConfig.cmake I get what I would consider a binary package. I saw that another user had reported the same issue here http://cmake.3232098.n2.nabble.com/How-to-deliver-a-source-code-package-td6505888.html but didn't really resolve it. That user resorted to make package_source, which does indeed pack up the source...and everything else in the directory. This is the expected CPack source packaging behavior. If you want to avoid that: 1) build out-of-source: http://www.cmake.org/Wiki/CMake_FAQ#Out-of-source_build_trees 2) setup appropriate value for CPACK_SOURCE_IGNORE_FILES see cpack --help-variable CPACK_SOURCE_IGNORE_FILES I tried throwing some dummy sandbox files in there, and they get zipped right up, too. Am I doing something wrong? I'm following the tutorial as well as I can tell. It seems like the command above should create a source package containing no binary files, and only the sources that you have told it to include. CPack source packaging is currently packaging the source directory while excluding CPACK_SOURCE_IGNORE_FILES that's unfortunately a very basic behavior. CPack cannot tel apart binary or source file unless you do out-of-source build. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] numerical option at compile time
Using autoconf, I could specify a numerical option using AC_ARG_ENABLE. This was useful for specifying a logging level at compile time. I could pass --enable-logging=8 to the configure script to enable deep logging. Is there a way to do this with cmake? Seems like option only allows yes or no answers. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] adding extra files to distribution
Hi, I'm new to CMake, but quite familiar with Autotools. I am trying to do something that is probably quite simple, but I cannot find any documentation for. The distribution creation mechanism is difficult to learn because of the lack of documentation. For instance, it seems (though I'm not sure of this) that the distribution will only contain files for which you've written an install rule, but I don't see that documented in any tutorial I've read. I was confused by that, being familiar with autotools, because I don't have to write those rules manually, and everything make has touched goes automatically into a distribution archive. I was surprised when I wrote the cpack commands into my CMakeLists.txt file only to get an empty archive. That's not meant as a cheer for autotools, just an anecdote from an autotools convert-in-progress. That leads me to my main question. If I have to have an install rule for everything, how do I add things to the distribution archive that I do not want to be installed? It's not uncommon to see projects with data or example directories that should never leave the source folders, and that never get installed. My google-fu has failed, because I cannot find how to include those files in the distribution yet not have them install anywhere. Thanks, Jack -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
