On 2009-08-25 19:19-0700 Alan W. Irwin wrote:
Oops. I had a screwup in the file dependencies for the project that was
importing PLplot libraries and modules. Once that was solved touch
ps.so made the component of the project that file depended on the ps target
build fine. Sorry for the no
On my Linux platform for CMake-2.6.4, dependencies work for imported library
targets but not imported module targets. To be specific if I touch
/home/software/plplot_cvs/installcmake/lib/libplplotd.so.9.6.2 (the location
of the imported library corresponding to the plplotd target) parts of the
bu
Thanks for the information. Unfortunately, I cannot find the
command prompt.
Xiangyun
--- On Tue, 8/25/09, David Cole wrote:
> From: David Cole
> Subject: Re: [CMake] Cross-compilation related question
> To: "Xiangyun Kong"
> Cc: "Tyler Roscoe" , cmake@cmake.org
> Date: Tuesday, August 25, 2
I am using the Visual Studio generator from the cmake binary distribution.
If I change flags using ADD_DEFINITIONS, I notice that it doesn't trigger a
rebuild of all the affected files.
Is this by design?
Juan
___
Powered by www.kitware.com
Visit other
Michael and Marcel have already posted helpful follow-ups to the
original question about compiling assembler files.
On Mon, Aug 24, 2009 at 01:38:13PM -0400, John Smith wrote:
> Most surely I am over-thinking it. After more local testing I think I
> understand how variables are processed in the
If you are using "NMake Makefiles" as the CMake generator, just be sure to
launch cmake (or cmake-gui) from the "Visual Studio x64 Cross Tools Command
Prompt" That should build x64 code for you without any special
adjustments out of the box.
HTH,
David
On Tue, Aug 25, 2009 at 12:56 PM, Xiangy
It can generate 64-bit code if the cross-compiler under bin/x86_amd64
is used.
Xiangyun
--- On Tue, 8/25/09, John Drescher wrote:
> From: John Drescher
> Subject: Re: [CMake] Cross-compilation related question
> To: "Xiangyun Kong"
> Cc: "Tyler Roscoe" , cmake@cmake.org
> Date: Tuesday, A
On Tue, Aug 25, 2009 at 12:56 PM, Xiangyun Kong wrote:
> Thanks. After I use the new generator, it always looks for the 32 bit
> cl.exe at vc_root/VC/bin,
> and complain that the cl.exe does not work, even though I set the
> PATH as vc_root/VC/bin/x86_amd64.
>
> I used to use NMake Makefile, whic
Thanks. After I use the new generator, it always looks for the 32 bit
cl.exe at vc_root/VC/bin,
and complain that the cl.exe does not work, even though I set the
PATH as vc_root/VC/bin/x86_amd64.
I used to use NMake Makefile, which does not complain about that.
Xiangyun
--- On Tue, 8/25/09, T
>
>
> Did you try the
>
> nm lib/libcallibs.a | grep print_double_array
>
> command?
>
> Thanks Michael!
With that command I spotted the mistake, it was already undefined before the
linking process. The function was in the header, but not on the c file (!!).
I recopied it nice & clean now.
Thank
On 25. Aug, 2009, at 16:06, Pol Monsó IRI wrote:
In case you'd like to see the compilation too, here's the complete
output.
The 1A's and 1B's real name is wammoves and inout and the 2C's is
wammates.
yarp is an external 3d party libraries framework for robot software,
it's
all under the
My message bounced due to size limitations (!?). I'm resending it without
the appended previous replies.
In case you'd like to see the compilation too, here's the complete output.
The 1A's and 1B's real name is wammoves and inout and the 2C's is wammates.
yarp is an external 3d party libraries fr
On Tue, Aug 25, 2009 at 9:06 AM, Pol Monsó IRI wrote:
> Hello cmake users!
>
> I'm quite new to cmake as well as makefiles, and i've bumped the same
> trouble twice. I'm trying to break a source code into several libraries and
> a main program. The scenario has one main executable called calClient
On 25. Aug, 2009, at 15:51, Pol Monsó IRI wrote:
DON'T EVER do something like this unless you really know what
you're doing.
The proper way of doing this is to use the Debug configuration at
configure-time:
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-Wall /path/to/
source
Thanks
>
> DON'T EVER do something like this unless you really know what you're doing.
> The proper way of doing this is to use the Debug configuration at
> configure-time:
>
> cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_FLAGS=-Wall /path/to/source
>
Thanks for the tip! I had just put the warnings on to f
On 25. Aug, 2009, at 15:23, David Ojeda wrote:
On Tue, Aug 25, 2009 at 12:47 PM, Andreas Pakulat
wrote:
On 25.08.09 12:37:46, David Ojeda wrote:
I have a shared library that I managed to compile and install using
cmake.
This is working great but now I want to use this library in another
On 25. Aug, 2009, at 15:23, David Ojeda wrote:
On Tue, Aug 25, 2009 at 12:47 PM, Andreas Pakulat
wrote:
On 25.08.09 12:37:46, David Ojeda wrote:
I have a shared library that I managed to compile and install using
cmake.
This is working great but now I want to use this library in another
On Tue, Aug 25, 2009 at 12:47 PM, Andreas Pakulat wrote:
> On 25.08.09 12:37:46, David Ojeda wrote:
> > I have a shared library that I managed to compile and install using
> cmake.
> > This is working great but now I want to use this library in another
> > cmake-based development. Normally, as wi
On 25. Aug, 2009, at 15:06, Pol Monsó IRI wrote:
Hello cmake users!
I'm quite new to cmake as well as makefiles, and i've bumped the same
trouble twice. I'm trying to break a source code into several
libraries and
a main program. The scenario has one main executable called
calClient which
Hello cmake users!
I'm quite new to cmake as well as makefiles, and i've bumped the same
trouble twice. I'm trying to break a source code into several libraries and
a main program. The scenario has one main executable called calClient which
uses functions from three libraries, let's say 1A 1B and
Just to be clear, did you build them with the 64bit command prompt
from Visual Studio? Otherwise how did you build them?
I ended up tweaking the cmake files that come with boost 1.39 in
order to remove the -s that is tagged onto the unittest libraries.
Otherwise not really sure what to do as this
On 25.08.09 12:37:46, David Ojeda wrote:
> I have a shared library that I managed to compile and install using cmake.
> This is working great but now I want to use this library in another
> cmake-based development. Normally, as with any other shared library, I use a
> FindPackage to get the include
Hello all,
I have a quick question regarding cmake modules.
I have a shared library that I managed to compile and install using cmake.
This is working great but now I want to use this library in another
cmake-based development. Normally, as with any other shared library, I use a
FindPackage to ge
Hi John,
I took a different approach to the problem you're describing.
Following the instructions on the Wiki
(http://www.cmake.org/Wiki/CMake/Assembler), I've written the three
required *ASM*.cmake files.
In the CMakeASM-Information.cmake file I've redefined the rule to
build .S files.
set(CMAKE
On Tue, Aug 25, 2009 at 12:08:10AM -0700, Xiangyun Kong wrote:
> I am trying to do a cross-compilation with CMake. I got a problem
> in creating a 64-bit shared library on a Win32 platform.
> The problem is the CMAKE is always appending the
> /machine:I386 following my arch setup /machine:x64.
Us
I am trying to do a cross-compilation with CMake. I got a problem
in creating a 64-bit shared library on a Win32 platform.
The problem is the CMAKE is always appending the
/machine:I386 following my arch setup /machine:x64.
My CMake file looks like,
CMAKE_FORCE_CXX_COMPILER(VC_CROSS_COMPILER
Hi all,
I've been bitten by this more than once. When specifying a module path
on the command line, you must not forget to make this an absolute path,
otherwise calling a macro from a (CMakeLists.txt file in a) subdirectory
will fail.
Would it be an idea to let CMake always convert a relative mod
27 matches
Mail list logo
