On Monday 20 July 2009, Robert Dailey wrote:
> On Mon, Jul 20, 2009 at 11:16 AM, John Drescher wrote:
> > On Mon, Jul 20, 2009 at 12:05 PM, Robert Dailey wrote:
> > > Thanks for the response Bill.
> > > I guess I could always use CodeBlocks & MinGW.
> > > Sincerely,
> > > Robert Dailey
> >
> > How
On Friday 17 July 2009, Mark Lohry wrote:
> I have this snipped in my cmakelists:
>
> IF( EXISTS "/someabsolutedirectory/unixem-1.8.2/include/glob2.h" )
> message( "/someabsolutedirectory/unixem-1.8.2/include/glob2.h exists" )
> ENDIF( EXISTS "/someabsolutedirectory/unixem-1.8.2/include/glob2.h
On Friday 17 July 2009, Mathieu Malaterre wrote:
> Hi,
>
>I did a quick search on google, and found nothing. But in case I
> missed something, is anyone using netbeans with cmake ? Has anyone
> worked on nbproject generator ?
AFAIK no.
If netbeans also supports makefile-based projects, writing
Does anyone have any insight to the below problem?
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf
Of Ashwin Chandra
Sent: Sunday, July 19, 2009 12:24 AM
To: cmake@cmake.org
Subject: [CMake] TRY_COMPILE NOT WORKING
I am using a custom compiler and during the initial
Hi all,
I am heading off to OSCON tomorrow, and will be presenting CMake on Wed
(http://www.kitware.com/news/home/browse/238). If anyone attending the
conference or is in the area, feel free to send me an email.
-Bill
--
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
On Mon, Jul 20, 2009 at 2:12 PM, Clinton Stimpson wrote:
>
> Would the general cmake solution for find_program/find_library do something
> like this:
> dumpbin /headers {some.lib|some.dll|some.exe} | findstr "machine" ?
> I get either AMD64 or x86 in the output from that.
Yes. Or something that
Would the general cmake solution for find_program/find_library do
something like this:
dumpbin /headers {some.lib|some.dll|some.exe} | findstr "machine" ?
I get either AMD64 or x86 in the output from that.
If find_program did it right, then gp_resolve_item would give me the
right .dll file.
On Mon, Jul 20, 2009 at 1:39 PM, Clinton Stimpson wrote:
>
> Thanks. Do you know if gp_resolve_item handles 64 and 32 bit binaries
> correctly on Windows?
Definitely not. On Windows, it uses find_program to find the dlls in the
PATH or in a list of directories provided by the caller... This is
Thanks. Do you know if gp_resolve_item handles 64 and 32 bit binaries
correctly on Windows?
"dumpbin /dependents" is used and it doesn't return full paths like ldd
does on Linux, or otool on Mac.
I put both in my PATH, so I can run both 32 and 64 bit programs. I just
wanted to make sure I wa
On Fri, Jul 17, 2009 at 6:48 PM, David Cole wrote:
> No. It's supposed to return the actual string that is referenced by the
> thing being analyzed. But you can call gp_resolve_item to get the full
> path... (There is a reason for this, although I can't remember what it is at
> the moment... If I
On Jul 20, 2009, at 12:25 PM, Robert Dailey wrote:
On Mon, Jul 20, 2009 at 11:16 AM, John Drescher
wrote:
On Mon, Jul 20, 2009 at 12:05 PM, Robert Dailey
wrote:
> Thanks for the response Bill.
> I guess I could always use CodeBlocks & MinGW.
> Sincerely,
> Robert Dailey
>
How about a singl
On Mon, Jul 20, 2009 at 11:16 AM, John Drescher wrote:
> On Mon, Jul 20, 2009 at 12:05 PM, Robert Dailey wrote:
> > Thanks for the response Bill.
> > I guess I could always use CodeBlocks & MinGW.
> > Sincerely,
> > Robert Dailey
> >
>
> How about a single source folder that is shared between two
On Mon, Jul 20, 2009 at 12:05 PM, Robert Dailey wrote:
> Thanks for the response Bill.
> I guess I could always use CodeBlocks & MinGW.
> Sincerely,
> Robert Dailey
>
How about a single source folder that is shared between two binary out
of source builds. One for Visual Studio and the second for C
Thanks for the response Bill.
I guess I could always use CodeBlocks & MinGW.
Sincerely,
Robert Dailey
On Mon, Jul 20, 2009 at 10:47 AM, Bill Hoffman wrote:
> Robert Dailey wrote:
>
>> Hello,
>>
>> I was wondering if it is possible to generate Visual Studio projects with
>> CMake that utilizes t
Robert Dailey wrote:
Hello,
I was wondering if it is possible to generate Visual Studio projects
with CMake that utilizes the GCC compiler instead of MSVC? I guess this
would technically be considered a cross-compiling setup, right? If this
is possible, how could I go about setting this up? T
Hello,
I was wondering if it is possible to generate Visual Studio projects with
CMake that utilizes the GCC compiler instead of MSVC? I guess this would
technically be considered a cross-compiling setup, right? If this is
possible, how could I go about setting this up? The reason why I want to do
On Jul 20, 2009, at 7:44 AM, Michael Wild wrote:
On 20. Jul, 2009, at 13:22, Steven Van Ingelgem wrote:
Hi,
I checked and in Darwin.cmake there are several items like
"CMAKE_OSX_ARCHITECTURES_DEFAULT" and
"CMAKE_OSX_DEPLOYMENT_TARGET_DEFAULT"... But...
I can't set them properly in my own
Hello fellow cmakers,
I've encountered a weired bug: Given that CMake is installed in
C:/Programme/CMake
and MATLAB's bin folder is on the path before cygwin's, cmake fails on
{{{
cmake_minimum_required(VERSION 2.6)
project(Foo C)
}}}
with
{{{
mkdir Debug
cd Debug && cmake -G"Unix Makefiles
On 20. Jul, 2009, at 13:22, Steven Van Ingelgem wrote:
Hi,
I checked and in Darwin.cmake there are several items like
"CMAKE_OSX_ARCHITECTURES_DEFAULT" and
"CMAKE_OSX_DEPLOYMENT_TARGET_DEFAULT"... But...
I can't set them properly in my own CMakeLists.txt file. As such,
when I set
the minimu
Hi,
I checked and in Darwin.cmake there are several items like
"CMAKE_OSX_ARCHITECTURES_DEFAULT" and
"CMAKE_OSX_DEPLOYMENT_TARGET_DEFAULT"... But...
I can't set them properly in my own CMakeLists.txt file. As such, when I set
the minimum version to 10.4, it still will try to compile against v10.5
20 matches
Mail list logo
