Thou shall receive the patch :)
On Thu, Sep 18, 2014 at 5:56 PM, David Cole wrote:
> My apologies. I take it back -- gcov apparently does work on the Mac
> nowadays.
>
> It is a ctest issue, then, and when using Xcode, ctest will need to look
> in some additional locations for the coverage data
Hi Alexey
I’ve updated our installers to get installed in CMakeMS instead of CMake, this
allows you to run both side by side.
If you want to rename the executable to be CMakeMS.exe, you can, I just felt
that for people relying on scripts, this could be a hard change to take.
~Gilles
--
Pow
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I have a project that consists of a library and an application that are
developed as two separated projects (different repos, separate cmake
setups, etc.). Let's call them "lib" and "app".
The app exports itself to ~/.cmake/ and creates a app
- Original Message -
> On 15/09/14 12:01, Daniele E. Domenichelli wrote:
> > Is there an alternative variable for CMAKE_CFG_INTDIR that can be used
> > in configure time, instead of build time?
> >
> > If there is not, is it safe to assume that the name of the directory is
> > equal to t
When i start "ctest -V -V -S CTestScript.cmake" manually on the command line, I
see the following messages:
Performing coverage
RegularExpression::compile(): ?+* follows nothing.
RegularExpression::compile(): Error in compile.
Best regards
> Am 17.09.2014 um 13:07 schrieb Rolf Eike Beer :
>
>
On 15/09/14 12:01, Daniele E. Domenichelli wrote:
> Is there an alternative variable for CMAKE_CFG_INTDIR that can be used
> in configure time, instead of build time?
>
> If there is not, is it safe to assume that the name of the directory is
> equal to the name of the current configuration?
Bum
My apologies. I take it back -- gcov apparently does work on the Mac
nowadays.
It is a ctest issue, then, and when using Xcode, ctest will need to
look in some additional locations for the coverage data files.
The source code is available -- patches welcome. :-)
D
--
Powered by www.kitwar
As David suggested I did following experiment.
I created two Test projects.
*Project1: *
*set(CTEST_SOURCE_DIRECTORY /Users/rajekumar/work/test-codes/TestUnix)*
*set(CTEST_BINARY_DIRECTORY /Users/rajekumar/work/test-codes/TestUnix/out)*
*set(CTEST_CMAKE_GENERATOR "Unix Makefiles")*
*set(CTEST
As I said in my previous response, I don't know anybody who is using
Xcode on the Mac, and also successfully producing a gcov coverage build.
If I were you, I would:
(1) use gcov on a Linux build of your software for coverage
measurement, using the "Unix Makefiles" generator and the right gcov
Hi,
Thanks for your responses.
As David mentioned I don't have to set the COVFILE if I don't have the
Bullseye.
I am already using the -fprofile-arcs -ftest-coverage hence .gcna & .gcno
files are getting generated.
Here is my CMakeLists.txt : http://pastebin.com/hQt2htkK
Here is my ctest script
Dear all,
I had the same issue some time ago with the Boost library.
The solution for me was to declare this library as "imported".
Here is an example:
add_library( curl UNKNOWN IMPORTED)
set_property(TARGET curl PROPERTY IMPORTED_LOCATION "/opt/XXX/lib/libcurl.so.4")
add_executable(xxx xxx.cpp)
It shouldn't truncate paths if specified... cause of course if we want to
test against a dev version then maybe the script knows better. But neither
should it add the full path if it's not specified in the script.
On Wed, Sep 17, 2014 at 11:59 PM, Nils Gladitz
wrote:
> On 09/18/2014 07:52 AM, V
On 09/18/2014 07:52 AM, Volker Pilipp wrote:
That actually does the trick. But it's not nice, because there are many
targets in the project.
Actually, I do not know about any use case, where cmake should replace a
full path to a lib
by its "-l" shortcut.
There are as far as I understand two use
13 matches
Mail list logo
