> Sigh, now I sent you the code from the wrong directory, but the code for
> the "Backend" component is virtually identical. I don't know how to use
> functions with CMake, so I simply made a verbatim copy of the below code
> in
> each subfolder and edited it to match the subfolder. So the Backen
I'd like to be able to get a backtrace when a test times out with ctest, so I
can analyze where the test was stuck, if at all.
I tried writing a fake test to tell me what signal ctest was using to kill a
timing out test, but it couldn't. I imagine this is because it uses SIGKILL
and I can't tr
Problem solved. I only needed to update to the most recent version. So I
figure I initially used a CMake that worked, then updated (which broke it),
and then updated (which repaired it).
Sorry for having wasted bandwidth and your time - when one uses bleeding
edge technologies, one has to rememb
FYI: On Linux (using CMake v2.8.8 and a recent Ninja), the Ninja build
works as expected. Just like it used to do on Windows. I now suspect the
problem is related to the CMake version I use (cmake version
2.8.8.20120605). I picked it up somewhere I don't recall and that's
probably the cause of t
>
> The existing "Software Process" filter is probably a good one to
> choose. You can see the blog postings that belong to that topic here:
>
> http://www.kitware.com/blog/home/browse/topic/7
Yep, that is perfect. Thanks!
Craig Scott | Senior Software Engineer
Southern Innovation | PO Box 3
Sigh, now I sent you the code from the wrong directory, but the code for
the "Backend" component is virtually identical. I don't know how to use
functions with CMake, so I simply made a verbatim copy of the below code in
each subfolder and edited it to match the subfolder. So the Backend
project
On Tue, Jun 26, 2012 at 5:29 PM, David Cole wrote:
> On Tue, Jun 26, 2012 at 5:51 PM, Robert Dailey
> wrote:
> > I'm including a Windows resource file (*.rc) in my add_executable()
> command,
> > but in VS2003 the build fails with RC1102 because all of my include
> > directories (and there are a
Here goes:
project(Driver)
set(PublicHeaders
"Driver.hpp"
"Setup.hpp"
)
set(PublishedHeaders "")
foreach(Header IN LISTS PublicHeaders)
get_filename_component(HeaderFilename "${Header}" NAME)
set(Source "${CMAKE_CURRENT_SOURCE_DIR}/${Header}")
set(Output "${CMAKE_CURRENT_BINAR
On Tue, Jun 26, 2012 at 6:40 PM, Mikael Lyngvig wrote:
> Ohh, sorry. Ninja says:
>
> [117/325] Building CXX object Driver/CMakeFiles/Driver.dir/Driver.cpp.obj
> FAILED: c:\Mingw64\bin\c++.exe -DNDEBUG
> -DBR0_BUILD_ASSERT=BR0_BUILD_ASSERT_DELETE
> -DBR0_BUILD_CHARSET=BR0_BUILD_CHARSET_ASCII
> -
Ohh, sorry. Ninja says:
[117/325] Building CXX object Driver/CMakeFiles/Driver.dir/Driver.cpp.obj
FAILED: c:\Mingw64\bin\c++.exe -DNDEBUG
-DBR0_BUILD_ASSERT=BR0_BUILD_ASSERT_DELETE
-DBR0_BUILD_CHARSET=BR0_BUILD_CHARSET_ASCII
-DBR0_BUILD_ENDIAN=BR0_BUILD_ENDIAN_LITTLE
-DBR0_BUILD_MODE=BR0_BUILD_
On Tue, Jun 26, 2012 at 6:30 PM, Mikael Lyngvig wrote:
> No, I delete the entire build tree (I build out of the source tree, btw).
>
> The procedure is as follows:
>
> rem foo contains the source code
> md foo-build
> cd foo-build
> cmake -G Ninja ..\foo
> ninja
> rem fails as de
No, I delete the entire build tree (I build out of the source tree, btw).
The procedure is as follows:
rem foo contains the source code
md foo-build
cd foo-build
cmake -G Ninja ..\foo
ninja
rem fails as described earlier
cd ..
rd /s /q foo-build
md foo-build
cd
On Tue, Jun 26, 2012 at 5:51 PM, Robert Dailey wrote:
> I'm including a Windows resource file (*.rc) in my add_executable() command,
> but in VS2003 the build fails with RC1102 because all of my include
> directories (and there are a TON) are being added to the resource file when
> it is compiled.
You can't switch generators in the same build tree without deleting
absolutely everything and starting over.
Is that what you're trying to do?
If you want a make build tree and a ninja build tree, you'll need two
separate build trees
HTH,
David
On Tue, Jun 26, 2012 at 4:45 PM, Mikael Lyng
I'm including a Windows resource file (*.rc) in my add_executable()
command, but in VS2003 the build fails with RC1102 because all of my
include directories (and there are a TON) are being added to the resource
file when it is compiled. I don't need the include directories for the
resource files, s
Hi,
I am a fan of Ninja. Since I started using it, everything's been built
much, much faster than before. Among other things because I use CMake to
publish headers to the binary directory so as to allow me to include the
headers with a relative path without having to move all my headers to a
cen
On Tue, Jun 26, 2012 at 2:56 PM, Eric Noulard wrote:
> 2012/6/26 Ben Medina :
>> You could subscribe to the Kitware blog. It's more than just CMake, but they
>> do announce all releases there.
>
> http://www.kitware.com/blog/
>
> The subscription is topic based may be a CMake or Kitware Software
>
2012/6/26 Ben Medina :
> You could subscribe to the Kitware blog. It's more than just CMake, but they
> do announce all releases there.
http://www.kitware.com/blog/
The subscription is topic based may be a CMake or Kitware Software
Release topic may be created
in order to have a finer grain filte
This would be great, at least it would improve my experience in two ways:
1) it would make sure that the library and interpreter are compatible and
2) it would make the library automatically locatable.
I agree I can use CMAKE_PREFIX_PATH to solve my immediate problem, though.
__
I know this is a kind of a big scope for a question, but it shadows a lot of
customization issues I have seen in many other topics.
To recap an earlier posting, I mentioned that I wanted to allow the user to add
some custom definitions in a more persistent way than the cache. Ben Morgan
sugges
> Actually, clearing the cache worked for FindPythonInterp but I still can't
> get FindPythonLibs.cmake to work. Same problem it can find the 2.4
> version but not the 2.7 version - and gives an error when 2.7 is required.
> Obviously, I cleared the cache this time. Again, is there a hint I ca
If I understand what's going on in that bug report, yes
add_dependency(imported_library EP_target) should work. But I found
that in fact it did not. So maybe that is a bug; if this was fixed in
2.8.4, I don't understand why I still have a problem.
On Tue, Jun 26, 2012 at 11:12 AM, Alexander Neu
Hi,
I have 3rd party supplied static library that we are repackaging
internally as a shared library.
Only a release build of the static library is supplied, thus I wish
our shared library to only have a release build, but I'd like the
shared library
available to the users of the library no matter
Στις 26/6/2012 18:22, ο/η Georgios Petasis έγραψε:
Στις 26/6/2012 17:56, ο/η Georgios Petasis έγραψε:
Hi all,
I am trying to cross-compile an application for windows, in a Fedora
17 box.
I have successfully cross-compiled/installed Tcl/Tk from sources.
And I want to also cross-compile my appl
Hi,
Am Dienstag, 26. Juni 2012 schrieb Ateljevich, Eli :
> Hi Andreas,
> Thanks. This must be what is happening. The references I saw to
> CMAKE_PREFIX_PATH suggested it was environment-only and needs to be known
> "at cmake time". That didn't fit my needs well and even though it seemed
> funny I
On Tuesday 26 June 2012, Kent Williams wrote:
> I meant to say 'the approach you use doesn't work, because imported
> libraries are targets to are targets to which you CANNOT add
> dependencies."
This should work since I think cmake 2.8.4.
http://public.kitware.com/Bug/view.php?id=10395
Or am I m
Hi Andreas,
Thanks. This must be what is happening. The references I saw to
CMAKE_PREFIX_PATH suggested it was environment-only and needs to be known "at
cmake time". That didn't fit my needs well and even though it seemed funny I
never challenged that.
You are suggesting it can be set in cmake
Thanks, Tim, This is very clear and complete and makes sense.
Don't change the compiler.
Do:
find_package(MPI REQUIRED)
add_definitions(${MPI_Fortran_COMPILE_FLAGS})
include_directories(${MPI_Fortran_INCLUDE_DIRS})
link_directories(${MPI_Fortran_LIBRARY_DIRS})
target_li
On Tue, Jun 26, 2012 at 11:22 AM, Georgios Petasis wrote:
> Στις 26/6/2012 17:56, ο/η Georgios Petasis έγραψε:
>
>> Hi all,
>>
>> I am trying to cross-compile an application for windows, in a Fedora 17
>> box.
>> I have successfully cross-compiled/installed Tcl/Tk from sources.
>> And I want to al
Στις 26/6/2012 17:56, ο/η Georgios Petasis έγραψε:
Hi all,
I am trying to cross-compile an application for windows, in a Fedora
17 box.
I have successfully cross-compiled/installed Tcl/Tk from sources.
And I want to also cross-compile my application, which uses cmake.
Is there a way to convin
I meant to say 'the approach you use doesn't work, because imported
libraries are targets to are targets to which you CANNOT add
dependencies."
On Tue, Jun 26, 2012 at 9:33 AM, Kent Williams
wrote:
> That seems like it should work, but it actually does not.
>
> There's two types of precedence in
Hi all,
I am trying to cross-compile an application for windows, in a Fedora 17 box.
I have successfully cross-compiled/installed Tcl/Tk from sources.
And I want to also cross-compile my application, which uses cmake.
Is there a way to convince cmake to use the platform tclsh (in order to
run s
Hello list,
I am having some trouble using bullseye and cmake on an ubuntu 12.04
system. It builds using bullseye, and for every .cpp file I indeed see
the bullseye header so that is ok. However, the COVFILE is not being
filled up with the data, only a small "empty" file is created of 512
byt
That seems like it should work, but it actually does not.
There's two types of precedence in CMake.
1. Textual -- as CMake munches through a project and its subdirectory,
it generates a build system where the build order is the same as the
textual order. In a single process build, for example:
Don't change the compiler.
Do:
find_package(MPI REQUIRED)
add_definitions(${MPI_Fortran_COMPILE_FLAGS})
include_directories(${MPI_Fortran_INCLUDE_DIRS})
link_directories(${MPI_Fortran_LIBRARY_DIRS})
target_link_libraries( ${MPI_Fortran_LIBRARIES})
if(MPI_EXTRA_LIBRARY)
target_link_libraries
I think I have to explained the thread correctly.
What is problem is that
currently it is copying a symbolic link
libicutu.so
but I want it to follow symbolic link and instead of copying symbolic link
it should copy it target file as symbolic link file name.
regards
Vivek Goel
On Tue, Jun 26,
Am Dienstag, 26. Juni 2012 um 14:19:56, schrieb Eric Noulard
> 2012/6/26 vivek goel :
> > hi,
> > I am building my custom library inside
> > lib/linux/gcc/${BIT}/lib/
> >
> > Currently I am using following command to install required library
> > INSTALL(DIRECTORY lib/linux/gcc/${BIT}/lib/
> >
cmake version 2.8.8
and icu is custom compiled.
regards
Vivek Goel
On Tue, Jun 26, 2012 at 5:49 PM, Eric Noulard wrote:
> 2012/6/26 vivek goel :
> > hi,
> > I am building my custom library inside
> > lib/linux/gcc/${BIT}/lib/
> >
> > Currently I am using following command to install required l
2012/6/26 vivek goel :
> hi,
> I am building my custom library inside
> lib/linux/gcc/${BIT}/lib/
>
> Currently I am using following command to install required library
> INSTALL(DIRECTORY lib/linux/gcc/${BIT}/lib/
> DESTINATION lib
> FILES_MATCHING PATTERN "*.so.*"
> PATTER
I need to add a custom command that varies based on configuration (with VS2010
generator). As far as I can see no direct way exists to do this.
I have tried to use the $<..> syntax but it keeps quoting the expression
add_library (foo SHARED IMPORTED GLOBAL)
set_target_properties(foo PROPERTIES
hi,
I am building my custom library inside
lib/linux/gcc/${BIT}/lib/
Currently I am using following command to install required library
INSTALL(DIRECTORY lib/linux/gcc/${BIT}/lib/
DESTINATION lib
FILES_MATCHING PATTERN "*.so.*"
PATTERN "icu" EXCLUDE
)
But it is not working
41 matches
Mail list logo
