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
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.
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?
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
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:
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
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
2011/2/14 Robert Bielik robert.bie...@xponaut.se:
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
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.
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 should
specify
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 Mon, Feb 14, 2011 at 4:14 AM, Andrea Galeazzi galea...@korg.it 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
On Sat, Feb 12, 2011 at 12:41 PM, Peter Kümmel syntheti...@gmx.net 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
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
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
On 14.02.2011 17:23, David Cole wrote:
On Sat, Feb 12, 2011 at 12:41 PM, Peter Kümmelsyntheti...@gmx.net 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
On Mon, Feb 14, 2011 at 12:02 PM, Peter Kümmel syntheti...@gmx.net wrote:
On 14.02.2011 17:23, David Cole wrote:
On Sat, Feb 12, 2011 at 12:41 PM, Peter Kümmelsyntheti...@gmx.net
wrote:
On 12.02.2011 18:26, Peter Kümmel wrote:
I wanna create a bundle on OSX with fixup_bundle but I have
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
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.
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
On Mon, Feb 14, 2011 at 11:09 AM, felix.more...@gmail.com 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
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
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
+++
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
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
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.
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 experts are
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 that
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
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 apposed
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
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 NONE)
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/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
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
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
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 path finds
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via ce6dbf6aedc7df2f065a7da3ea203f6c10b49d82 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 42a5e8d978a316620027b32eeb976a5b8758d8ba (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 6720f97d3b07f89af283024d29fad2194edd06f7 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9b3dc16d9741c4ed3f45eb2cde452bf1d074a088 (commit)
via
41 matches
Mail list logo