> The reason I'm asking this question is because of how I handle unit
> tests in CMake right now. Instead of just defining an executable
> target for the test and then adding a link dependency on the library
> containing the class or set of classes to be tested, I am manually
> pulling in the CPP a
> This is the approach that the LLVM project uses which is very simple
> and very clean (take a look at the sources). This also works very well
> for installing your header files, the contents of ${CMAKE_SOURCE_DIR}
> just need to be copied into /usr/include .
Oops I meant to say the contents of
On Thu, Jun 18, 2015 at 1:43 AM, Robert Dailey
wrote:
> On Wed, Jun 17, 2015 at 4:31 PM, Dan Liew wrote:
> > On 17 June 2015 at 12:28, Robert Dailey
> wrote:
> >> Is there a way to only take (recursively) the include directiories from
> >> a target or set of targets? I know that include directo
On Wed, Jun 17, 2015 at 4:31 PM, Dan Liew wrote:
> On 17 June 2015 at 12:28, Robert Dailey wrote:
>> Is there a way to only take (recursively) the include directiories from
>> a target or set of targets? I know that include directories propagate
>> when passing targets to target_link_libraries(),
2015-06-17 21:00 GMT+02:00 Ondřej Čertík :
> and just use CMAKE_PREFIX_PATH instead of COMMON_DIR. I tried it in
> our code and it works.
the idea is, that there is no need for PKG1_INCLUDE_DIRS, no
PKG1_LIBRARIES and no PKG1_DIR
just one path per dependency in CMAKE_PREFIX_PATH
(or per group of d
On 17 June 2015 at 12:28, Robert Dailey wrote:
> Is there a way to only take (recursively) the include directiories from
> a target or set of targets? I know that include directories propagate
> when passing targets to target_link_libraries(), but I do not want to
> link the libs; I only want the
Klaim - Joël Lamotte wrote:
> Thinking about boost, if package files works well with header-only
> libraries (which I
> suppose it should as long as the boost define header-only targets)
> then it would be very useful indeed.
Yes, I wrote some cmake 3.0 features specifically for the Boost use cas
On 17 June 2015 at 20:50, Stephen Kelly wrote:
> Klaim - Joël Lamotte wrote:
>
> > I didn't realize at all that the FindPackage way is supposed to be
> > obsolete now.
>
> It is not obsolete, but it is not a good approach (since CMake 2.6.0
> already) if the upstream uses cmake, because config fi
Is there a way to only take (recursively) the include directories from
a target or set of targets? I know that include directories propagate
when passing targets to target_link_libraries(), but I do not want to
link the libs; I only want the include directories.
How can I do this? Thanks.
--
Pow
Hi Oto,
On Wed, Jun 17, 2015 at 11:18 AM, Oto Petřík wrote:
> Hi,
>
>> Let's say my project wants to depend on a library PKG1 (here PKG1 can
>> be MPFR, MPC, PTHREAD, GMP, BZIP2, you name it). Let's say the library
>> is installed in $PKG1/include, $PKG1/lib, alternatively, all my
>> dependencies
Klaim - Joël Lamotte wrote:
> I didn't realize at all that the FindPackage way is supposed to be
> obsolete now.
It is not obsolete, but it is not a good approach (since CMake 2.6.0
already) if the upstream uses cmake, because config file packages provide a
better experience for downstreams
h
On 17/06/15 16:29, Michael Jackson wrote:
> Just to follow up with this issue in case anyone else has issues with Xcode
> here is what happened. Thanks to Gregor for taking a look at the generated
> project file he was able to identify an issue where there were file paths in
> the form of "//" i
Hi,
When using CFLAGS=-Werror
$ check_library_exists(m sqrt "" HAVE_LIBM)
fails to give the correct result.
A very similar issue has been reported before for CHECK_FUNCTION_EXISTS
http://www.cmake.org/Bug/view.php?id=8246
There the recommendation was to use CHECK_SYMBOL_EXISTS instead.
My quest
Hi,
> Let's say my project wants to depend on a library PKG1 (here PKG1 can
> be MPFR, MPC, PTHREAD, GMP, BZIP2, you name it). Let's say the library
> is installed in $PKG1/include, $PKG1/lib, alternatively, all my
> dependencies are installed in $HASHSTACK/include and $HASHSTACK/lib,
> or perhaps
I would like to use OBJECT libraries with CUDA.
If I try
cuda_add_library(foo OBJECT )
I get
CMake Error at
/opt/contrib-clangcxx11/cmake-3.2.2-ser/share/cmake-3.2/Modules/FindCUDA.cmake:1518
(add_library):
OBJECT library "txsbaseobj" contains:
txsbaseobj_generated_TxsGpuInterpolato
>I've scoured the cf77 docs and found nothing native so I've responded to
>concurrent and again asked how I can find unique identifying information for
>cmake to latch onto. Will report back.
Please see the response below about uniquely identifying cf77. Does this seem
doable? How do we proc
On Jun 16, 2015, at 3:27 PM, Gregor Jasny wrote:
> Hello,
>
> I applied some fixes to what becomes CMake 3.3. could you please test
> the release candidate?
>
> On 16/06/15 16:27, Michael Jackson wrote:
>> Running OS X 10.8.5 with Xcode 5.1.1 and Cmake 3.2.x and 3.3.RC and neither
>> generate
On 16 June 2015 at 11:49, Johannes Zarl-Zierl
wrote:
> On Monday 15 June 2015 22:43:41 you wrote:
> > Just a last question: I assume that most find module scripts distributed
> > with cmake are
> > not using this feature at the moment, right?
>
> Sadly, no.
>
> > After reading your explaination I
Hi!
i get an error at cmake configure step on windows with -G "MinGW Makefiles", if
the OpenSSH bin folder is in the PATH environment cause cmake detects sh.exe
and then throws an error. This seems to be intended due to this link
http://www.cmake.org/Wiki/CMake_MinGW_Compiler_Issues
But if i now
19 matches
Mail list logo
