On 14.02.11 16:18:09, Clinton Stimpson wrote:
> On Monday, February 14, 2011 03:27:11 pm Harinarayan Krishnan wrote:
> > Hi All,
> >
> > I was trying to build the VisIt software package on my Mac OSX 1.5 . This
> > package uses Qt 4.6.1 during its build. I ran into an issue where the
> > QtCore pa
Hello Michael,
thanks a lot for looking into my problem. It turns out that Mac OS X behaves
a bit oddly, in the sense that the name of the directory of installation is in
the libraries as well as in the executable. I solved the problem with a single
line setting the properties of the library
Hi,
I have a question on the use of CPack. I have CMake setup to generate binaries
and shared libraries. Up until now I have only created a TGZ with rpath set to
".". This has worked nicely, but now I would like to create a Debian package
for proper installation. I have added DEB to CPACK_G
On 02/14/2011 03:11 AM, Carminati Federico wrote:
> Hello Michael,
> thanks for your answer. Indeed it is a very complex built system, so the
> link line is
>
> /opt/gcc-4.5.1/bin/g++-DDarwin -DDATE_SYS=Darwin -Dlong32='int'
> -Dlong64='long long' -DdatePointer='long' -O -g -pipe -fbound
Hi,
Adding a NO_DEFAULT_PATH or a NO_CMAKE_SYSTEM_PATH was my solution as well
but I would prefer not to edit FindQt4.cmake as a final solution. I don't
know if this is a bug with FIND_PATH. I have seen this issue on a Mac, I am
not sure about Linux or Windows.
Thanks,
Hari
On Feb 14, 2011 3:19
On 02/15/2011 12:58 AM, John McGehee wrote:
> I have a custom command that depends on a custom target. In the example
> below, it is as if
>ADD_CUSTOM_COMMAND(... DEPENDS t ...)
> has no effect:
>
> # CMakeLists.txt:
> CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
> PROJECT(CUSTOMDEPENDS N
I have a custom command that depends on a custom target. In the example below,
it is as if
ADD_CUSTOM_COMMAND(... DEPENDS t ...)
has no effect:
# CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CUSTOMDEPENDS NONE)
ADD_CUSTOM_TARGET(t
${CMAKE_COMMAND} -E echo "Build
On Monday, February 14, 2011 03:27:11 pm Harinarayan Krishnan wrote:
> Hi All,
>
> I was trying to build the VisIt software package on my Mac OSX 1.5 . This
> package uses Qt 4.6.1 during its build. I ran into an issue where the
> QtCore path finds my globally installed version of Qt (4.7) as appo
Hi All,
I was trying to build the VisIt software package on my Mac OSX 1.5 . This
package uses Qt 4.6.1 during its build. I ran into an issue where the QtCore
path finds my globally installed version of Qt (4.7) as apposed to the Qt
(4.6.1).
While digging around I found that FIND_PATH (code inclu
On 2/14/2011 3:37 PM, Jean-Christophe Fillion-Robin wrote:
Last night, I started a topic named "ninja-generator" on my github ...
see https://github.com/jcfr/CMake/tree/ninja-generator
Right now, I just copied all the file related to CMakefile generator and
named using the "Ninja" prefix.
Is th
Last night, I started a topic named "ninja-generator" on my github ... see
https://github.com/jcfr/CMake/tree/ninja-generator
Right now, I just copied all the file related to CMakefile generator and
named using the "Ninja" prefix.
Is that the right approach ? Comment from "CMake Internals" expert
David,
Thank you for your answer. I don't know much about Visual Studio code
coverage, but it seems to be a new feature of VS 2010. I never tested it.
You can find more information at
http://msdn.microsoft.com/en-us/library/ms182496.aspx
However, only 32bits applications seems supported. M
This will FAIL on windows. MSVC defines "long" as 32 bits on BOTH 32 and 64
bit compiles. Stick with the already defined CMAKE_SIZE_OF_VOID_P instead. It
is known to work correctly on all the systems that CMake defines.
As mentioned earlier, when building for OS X and universal binaries there
Sorry, I meant LONG actually, I was a bit tired when I wrote the mail. Perhaps
I should change to VOID instead, thanks for the tip.
This was my previous code:
INCLUDE(CheckTypeSize)
CHECK_TYPE_SIZE (long LONG_SIZE) #4 if 32bit, 8 if 64bit...
I don't actually build for Windows yet, so I suppose t
Attached a small patch for the fixup_bundle documentation
which would helped me a lot when I've stared using fixup_bundle.
Peter
diff --git a/Modules/BundleUtilities.cmake b/Modules/BundleUtilities.cmake
index 44f2c20..6811fb6 100644
--- a/Modules/BundleUtilities.cmake
+++ b/Modules/BundleUtiliti
On 14.02.2011 18:14, Michael Jackson wrote:
You may want to take a look at some of the macros that I have created just for
this purpose: copying my own plugins plus some of Qt's plugins into the
application bundle.
http://scm.bluequartz.net/support-libraries/cmp/trees/master
Take a look at the
On Mon, Feb 14, 2011 at 11:09 AM, wrote:
> Hi,
>
> On the wiki, it is mentioned that code coverage is supported using gcov and
> Bullseye. However on the CMake dashboard, under the code coverage section,
> you can see that the build name for the "dash22.kitware" site is
> "Win32-vs9-Release-Cover
You may want to take a look at some of the macros that I have created just for
this purpose: copying my own plugins plus some of Qt's plugins into the
application bundle.
http://scm.bluequartz.net/support-libraries/cmp/trees/master
Take a look at the cmpCMakeMacros.cmake file
One of my project
My apologies if this question has been asked and answered previously.I
have a CMake system that I use for cross compilation for iOS software (ie
reset CMAKE_C_COMPILER, etc...). Everything works great, except for the
following usage scenario:
1. configure build system for iOS build.
2. buil
Hi,
On the wiki, it is mentioned that code coverage is supported using gcov and
Bullseye. However on the CMake dashboard, under the code coverage section,
you can see that the build name for the "dash22.kitware" site
is "Win32-vs9-Release-Coverage". I wondered if this site is using Bulleye
On Mon, Feb 14, 2011 at 12:02 PM, Peter Kümmel wrote:
> On 14.02.2011 17:23, David Cole wrote:
>
>> On Sat, Feb 12, 2011 at 12:41 PM, Peter Kümmel
>> wrote:
>>
>> On 12.02.2011 18:26, Peter Kümmel wrote:
>>>
>>> I wanna create a bundle on OSX with fixup_bundle but I have problems
with
>>>
On 14.02.2011 17:23, David Cole wrote:
On Sat, Feb 12, 2011 at 12:41 PM, Peter Kümmel wrote:
On 12.02.2011 18:26, Peter Kümmel wrote:
I wanna create a bundle on OSX with fixup_bundle but I have problems with
plugins.
The plugins are build with add_library(MODULE) into
${CMAKE_BINARY_DIR}/pl
I am using CPACK - NSIS to generate my installer.
When am trying to re-install my app on an existing installation it installs.
But, when the app is running am not able to install it (the windows OS gives
me some error). To avoid this I want to add a message box which says "The
APP is already runn
On 02/14/2011 10:02 AM, Yngve Inntjore Levinsen wrote:
> If you want everything linked statically I believe you can use the variable,
> BUILD_SHARED_LIBS, something like
> OPTION( BUILD_SHARED_LIBS "Set to OFF to build static libraries" OFF )
> I do believe it will still use dynamic libraries if
On Sat, Feb 12, 2011 at 12:41 PM, Peter Kümmel wrote:
> On 12.02.2011 18:26, Peter Kümmel wrote:
>
>> I wanna create a bundle on OSX with fixup_bundle but I have problems with
>> plugins.
>>
>> The plugins are build with add_library(MODULE) into
>> ${CMAKE_BINARY_DIR}/plugins.
>>
>> set(app ${CMA
On Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi wrote:
> I'm very interested in the feature discussed here:
> http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably it
> won't enter into 2.8.4, so do you have any rough idea about when 2.8.5
will
> be released? Or better, do you ha
Michael Wild skrev 2011-02-14 15:55:
Probably you could make the find_library call more robust by appropriate
PATHS options, but I currently don't have a windows available, so I
can't check whether the registry would help.
The DXSDK_DIR environment variable is set to correct location, so I use
On 02/14/2011 03:45 PM, Robert Bielik wrote:
> Eric Noulard skrev 2011-02-14 15:42:
>>> I seem to be missing something, cause I cannot find a target property
>>> for
>>> setting additional library directories (for a MSVC project)
>>
>> Usually you do not specify "additional lib directories" you sho
Eric Noulard skrev 2011-02-14 15:42:
I seem to be missing something, cause I cannot find a target property for
setting additional library directories (for a MSVC project)
Usually you do not specify "additional lib directories" you should
specify all libs you need with "target_link_libraries".
2011/2/14 Robert Bielik :
> Hi all,
>
> I seem to be missing something, cause I cannot find a target property for
> setting additional library directories (for a MSVC project)
Usually you do not specify "additional lib directories" you should
specify all libs you need with "target_link_libraries".
Hi all,
I seem to be missing something, cause I cannot find a target property for
setting additional library directories (for a MSVC project)
Help!?
TIA
/Rob
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.ki
> I have done the same thing myself, using size of INT instead of P which is
> of course following the exact same logic.
> After attempting several strategies I found this one to be the safest way
> to detect 32/64bit systems, so I recommend using SIZEOF as well.
sizeof(int) is 4 on basically all
Il 12/02/2011 19.58, Alexander Neundorf ha scritto:
On Friday 11 February 2011, Andrea Galeazzi wrote:
Alexander Neundorf ha scritto:
On Wednesday 09 February 2011, Andrea Galeazzi wrote:
Il 08/02/2011 17.58, Alexander Neundorf ha scritto:
On Tuesday 08 February 2011, Andrea Galeazzi wrote:
But there's one important pitfall: fat binaries. E.g. on Mac OS X if
CMAKE_OSX_ARCHITECTURES is set to multiple architectures (especially, if
they're mixed 32/64 bit) you can't rely on the value of
CMAKE_SIZEOF_VOID_P. You can't do anything about this stuff in your
CMake code, because you are compi
I'm very interested in the feature discussed here:
http://www.mail-archive.com/cmake@cmake.org/msg34587.html but probably
it won't enter into 2.8.4, so do you have any rough idea about when
2.8.5 will be released? Or better, do you have a periodic schedule
planning the releases?
If you want everything linked statically I believe you can use the variable,
BUILD_SHARED_LIBS, something like
OPTION( BUILD_SHARED_LIBS "Set to OFF to build static libraries" OFF )
I do believe it will still use dynamic libraries if static aren't available,
but I am unsure about that part.
Che
I have done the same thing myself, using size of INT instead of P which is of
course following the exact same logic.
After attempting several strategies I found this one to be the safest way to
detect 32/64bit systems, so I recommend using SIZEOF as well.
Cheers,
Yngve
On Sunday 13 February 20
37 matches
Mail list logo
