Re: [CMake] Getting coredump from ctest

2013/3/21 Martin Sustrik > Hi, > > Is there a way to get a coredumps from failures that happen durink 'make > test'? > > Thanks, > Martin > -- > > What do you mean by "get coredump"? Any crash should produce core if ulimit -c unlimited set. -- Best Regards, Sergei Nikulov -- Powered by www.kitw

Re: [CMake] Is there an easy way to time how long build parts take.

2013/3/21 Miller Henry : > Our build it taking a long time, (15+ minutes even when with a massive build > farm to distribute compiles across), and the question keeps coming up: what > is actually taking so long. Is there an easy way to measure? Your build certainly have a lot of different targets

Re: [CMake] 2.8.11rc1 - OSX Lion and Xcode 4.4.1

On 22/03/13 2:19 AM, Sean McBride wrote: On Thu, 21 Mar 2013 22:27:41 +1100, Nicholas Yue said: I am trying out CMake 2.8.11rc1 on OS X Lion with XCode 4.4.1 My dashboard here: Is running OS X 10.7.5, CMake 2.8.11rc1, and Xcode 4.4

[CMake] Getting coredump from ctest

Hi, Is there a way to get a coredumps from failures that happen durink 'make test'? Thanks, Martin -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://w

[CMake] Building an external library based on autotools

Hello, I'm having a hard time figuring out which solution to choose to build a library (FFmpeg) based on autotools from CMake, and I have the impression I'm going the tricky way. I know how to run the FFmpeg's configure and make scripts with the right options from a bash script. I made a CMake

[CMake] Is there an easy way to time how long build parts take.

Our build it taking a long time, (15+ minutes even when with a massive build farm to distribute compiles across), and the question keeps coming up: what is actually taking so long. Is there an easy way to measure? If there are some top 10 files we might be able to split them (reducing some inc

Re: [CMake] patch proposal for PythonInterp

Yngve Inntjore Levinsen wrote: > On 21. mars 2013 12:00, Rolf Eike Beer wrote: > > Am 21.03.2013 11:03, schrieb Yngve Inntjore Levinsen: > >> Hi, > >> > >> I have a suggestion for the PythonInterp. On a system I am compiling my > >> code on, I need to find the python binary which is newer than 2.5

Re: [CMake] Accessing data

Eric Noulard said: > Instead of copying you could use > cmake -E create_symlink > but this won't work on Windows. If building on Windows is required, you could make a symlink, hardlink, or junction point. If on Vista or later, look at the command mklink. Symlinks require admin privileges, but I

Re: [CMake] patch proposal for PythonInterp

On 21. mars 2013 12:00, Rolf Eike Beer wrote: > Am 21.03.2013 11:03, schrieb Yngve Inntjore Levinsen: >> Hi, >> >> I have a suggestion for the PythonInterp. On a system I am compiling my >> code on, I need to find the python binary which is newer than 2.5. >> However, the default /usr/bin/python is

Re: [CMake] 2.8.11rc1 - OSX Lion and Xcode 4.4.1

On Thu, 21 Mar 2013 22:27:41 +1100, Nicholas Yue said: > I am trying out CMake 2.8.11rc1 on OS X Lion with XCode 4.4.1 My dashboard here: Is running OS X 10.7.5, CMake 2.8.11rc1, and Xcode 4.4.1. It's able to build (nightly) CMake it

Re: [CMake] How to avoid having /D _MBCS ?

On Thursday 21 March 2013 15:29:18 John Drescher wrote: > On Thu, Mar 21, 2013 at 10:20 AM, Martin Koller wrote: > > In my win project, when I use the visual studio generator (64bit), I always > > get the /D _MBCS flag in the compiler options > > (started with msbuild). > > When I generate Makefi

Re: [CMake] How to avoid having /D _MBCS ?

On Thu, Mar 21, 2013 at 10:20 AM, Martin Koller wrote: > In my win project, when I use the visual studio generator (64bit), I always > get the /D _MBCS flag in the compiler options > (started with msbuild). > When I generate Makefiles with the same project (JOM NMakefiles), _MBCS is > not define

[CMake] How to avoid having /D _MBCS ?

In my win project, when I use the visual studio generator (64bit), I always get the /D _MBCS flag in the compiler options (started with msbuild). When I generate Makefiles with the same project (JOM NMakefiles), _MBCS is not defined. I do not want to have it defined. How can I avoid it and still

Re: [CMake] CPack RPM with COMPONENTS packaging

2013/3/20 Theodore Papadopoulo : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Actually, this patch works better... and is much simpler. Yes right. Some other modifications of yours in Source/cmFindBase.cxx Source/cmFindLibraryCommand.cxx Do not belong to that problem, right? I'll strip t

Re: [CMake] CPack RPM with COMPONENTS packaging

2013/3/20 Theodore Papadopoulo : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/20/2013 05:01 PM, Eric Noulard wrote: >> 2013/3/20 Theodore Papadopoulo : > And do you observe differences when you do that? >>> >>> As I said above, no there is no difference in my case because the >

[CMake] 2.8.11rc1 - OSX Lion and Xcode 4.4.1

Hi, I am trying out CMake 2.8.11rc1 on OS X Lion with XCode 4.4.1 When I use the "Xcode" generator, I get the following messages = -- The C compiler identification is unknown -- The CXX compiler identification is unknown --

Re: [CMake] patch proposal for PythonInterp

Am 21.03.2013 11:03, schrieb Yngve Inntjore Levinsen: Hi, I have a suggestion for the PythonInterp. On a system I am compiling my code on, I need to find the python binary which is newer than 2.5. However, the default /usr/bin/python is 2.4. If I then set the variable (which is not documented

[CMake] 2.8.11rc1 CMAKE_LINKER and CMAKE_OBJCOPY sporadically vanishing

I am trying out CMake 2.8.11rc1 on windows and linux continuous build clients. During clean full rebuilds everything seems to work fine. During incremental "Continuous" builds with reused build directories however CMAKE_OBJCOPY (on linux gcc; used by me manually) and CMAKE_LINKER (on windows M

[CMake] patch proposal for PythonInterp

Hi, I have a suggestion for the PythonInterp. On a system I am compiling my code on, I need to find the python binary which is newer than 2.5. However, the default /usr/bin/python is 2.4. If I then set the variable (which is not documented in the header by the way) PythonInterp_FIND_VERSION to 2.