On 09/23/2011 09:20 PM, Yifei Li wrote:
> On Sep 22, 2011, at 2:39 PM, David Cole wrote:
>
>> It should always be a full path for a valid found library. Under what
>> circumstances are you getting exactly "mylib" ? ?
> Here is a real example:
>
> find_package(OpenMesh)
> message("${OPENMESH_LIBRA
In general it's better to make your project into an ExternalProject
itself, and have it depend on all other ExternalProject upon which it
depends.
That way all prerequisites get built, and then your package get built.
It ensures that all prerequisites are fully built and installed
before your pro
It's the same as "make clean; make", so it's not just a Visual Studio thing.
On Mon, Sep 26, 2011 at 10:45 AM, Rolf Eike Beer wrote:
> Am Montag, 26. September 2011, 10:37:57 schrieb Ben Medina:
>> John is right. The external project may be at the bottom of a chain of
>> (my own) project dependen
OS X CMake 2.8.5
I was trying to get our nightly build script correct, and ran into this:
MakeCommand:
Cannot find MakeCommand key in the DartConfiguration.tcl
First of all we don't use Dart, there is no DartConfiguration.tcl in
the build directory. There is a CTestConfiguration.ini, which does
On 09/22/2011 01:00 PM, Marco Corvo wrote:
> Hi all,
>
> I thought I came up with a solution for this problem, but looks like I'm
> still not doing the right thing.
>
> My project is made of many tens of packages, everyone with its nice
> CMakeLists.txt. What I'd like to do is to have the freed
Am Montag, 26. September 2011, 10:37:57 schrieb Ben Medina:
> John is right. The external project may be at the bottom of a chain of
> (my own) project dependencies. I need to preserve the ability to
> easily rebuild just my projects (and their dependencies), not external
> projects. Think of Exter
John is right. The external project may be at the bottom of a chain of
(my own) project dependencies. I need to preserve the ability to
easily rebuild just my projects (and their dependencies), not external
projects. Think of ExternalProject as a replacement for pre-built
libraries, and you'll see
On 9/25/2011 8:54 PM, Albert Chin wrote:
It is listed as "static" because cmake always uses a
path/to/libmodman.sl when invoking the linker.
CMake prior to 2.6 always used the -L and -l split. That led to endless
problems with search path ordering, static v. shared searches, etc. that
made it
I am using CMake to run SWIG to generate C# wrapper files for a
project. While the attached CMakeLists.txt file produces a Visual
Studio solutions that builds the C++ library, C# wrapper library and
C# prototype executable I don't know first if I am using CMake
correctly in this case. Secondly I am
On 9/24/2011 1:08 PM, Brian Davis wrote:
> I guess at the end of the day what you are talking about is a static
code analysis tool for the CMake language. Those tools look at all
possible branches of code and try to detect errors.
What I would like to see at a minimum is a CMake Debugger showi
I'm currently evaluating a good tool to introduce a continuous
integration model in my workflow. Because I use CMake to manage all my
projects, I'd like to also use CTest/CDash in order to accomplish such
task. I start to read something about it but I didn't find the right
answers to some quest
11 matches
Mail list logo
