On Tue, Apr 28, 2009 at 10:12:17AM +0800, brice rebsamen wrote:
> >>>How to know the version of an installed library? My code has #if
> >>>macros to handle different APIs. So I would need to get the version
> >>>and set 2 variables (MAJOR and MINOR) and pass them to the compiler
> >>>(-D).
> >>>
brice rebsamen wrote:
Ralf Habacker wrote:
brice rebsamen schrieb:
How to know the version of an installed library? My code has #if
macros to handle different APIs. So I would need to get the version
and set 2 variables (MAJOR and MINOR) and pass them to the compiler
(-D).
To be more precis
On 2009-04-28 01:01+0200 Andreas Pakulat wrote:
On 27.04.09 14:50:47, Alan W. Irwin wrote:
On 2009-04-27 18:47+0200 Anders Backman wrote:
I have a problem where I pack the necessary stuff from qt into a dependency
zip file (.h, .lib, .dll and qmake.exe).
I have the path to qmake setup, so tha
On 27.04.09 14:50:47, Alan W. Irwin wrote:
> On 2009-04-27 18:47+0200 Anders Backman wrote:
>> I have a problem where I pack the necessary stuff from qt into a dependency
>> zip file (.h, .lib, .dll and qmake.exe).
>>
>> I have the path to qmake setup, so that qmake can be found.
>>
>> Then I unpac
On 2009-04-27 18:47+0200 Anders Backman wrote:
Hi all.
I have a problem where I pack the necessary stuff from qt into a dependency
zip file (.h, .lib, .dll and qmake.exe).
I have the path to qmake setup, so that qmake can be found.
Then I unpack that to some specified directory and run cmake o
I need to understand how to use CMake command line variables to specify the
install name and rpath settings when building VTK and installing it into a
destroot (which is not the final installation path). In macports,
everything is installed into a "holding bay" that is defined by $DESTROOT.
>From
Andreas Pakulat schrieb:
On 27.04.09 19:54:12, Anders Backman wrote:
Ah thanks.But how to know what to copy from QT so that one can still build
applications?
That is, what is needed so that CMake accepts the copied files as a complete
qt installation?
.lib files,
.dll:s
That, the exe
On Monday 27 April 2009, Marcel Loose wrote:
> Hi all,
>
> I was wondering whether it's possible to somehow redefine an existing
> target within a nested project. Let me give an example.
>
> Suppose my CMake project has the following structure
>
> bigproject
> subproject_1
> subproject_2
>
> wh
Have you looked here?
http://doc.trolltech.com/4.5/installation.html
If you still have problems getting a working Qt installation, you can as
the Qt list.
CMake will work with any good installation of Qt.
Clint
Anders Backman wrote:
Ah thanks.
But how to know what to copy from QT so that one
On 27.04.09 19:54:12, Anders Backman wrote:
> Ah thanks.But how to know what to copy from QT so that one can still build
> applications?
>
> That is, what is needed so that CMake accepts the copied files as a complete
> qt installation?
>
> .lib files,
> .dll:s
That, the executables, the headers
Hi,
I am trying to port CMake to VMS. For the first pass I am going to use
the GNV tools and gmake.I am very close, but I am having trouble
with files that have more than one "." in the name. CMake uses files
like that in several places, as do many CMake based projects.
Assuming I use POS
Ah thanks.But how to know what to copy from QT so that one can still build
applications?
That is, what is needed so that CMake accepts the copied files as a complete
qt installation?
.lib files,
.dll:s
which plugins?
mkspecs
which exe files?
Do I have to parse the FindQt4.cmake file, or is ther
Am Montag 27 April 2009 18:47:07 schrieb Anders Backman:
> Hi all.
> I have a problem where I pack the necessary stuff from qt into a dependency
> zip file (.h, .lib, .dll and qmake.exe).
>
> I have the path to qmake setup, so that qmake can be found.
>
> Then I unpack that to some specified direct
Thank you!
-Dieter
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com]
> Sent: Monday, April 27, 2009 3:46 PM
> To: doberkofler.li...@gmail.com
> Cc: billl...@nycap.rr.com; CMake@cmake.org
> Subject: Re: [CMake] Problem with NMake generator after
> upgrade from 2.4.6 t
On Mon, Apr 27, 2009 at 03:33:39PM +0200, Marcel Loose wrote:
> Now, suppose there's some generic target (e.g. 'check') that I would
> like to be defined for each of these projects, such that I can do
>
> $ cd /path/to/build/directory/bigproject && make check
>
> but also
>
> $ cd /path/to/b
Hi all.
I have a problem where I pack the necessary stuff from qt into a dependency
zip file (.h, .lib, .dll and qmake.exe).
I have the path to qmake setup, so that qmake can be found.
Then I unpack that to some specified directory and run cmake on my own code.
My projectgs CMakeLists.txt call F
On Mon, Apr 27, 2009 at 17:51, Bill Hoffman wrote:
> Daniel Blezek wrote:
>>
>> Hi Bill,
>>
>> I bumped into this problem as well. We had several classes that were
>> compiled, but no methods in them were run. CTest ignored them and we
>> didn't
>> have any coverage information on our dashboard
Daniel Blezek wrote:
Hi Bill,
I bumped into this problem as well. We had several classes that were
compiled, but no methods in them were run. CTest ignored them and we didn't
have any coverage information on our dashboard. I would second this
recommendation to accumulate coverage based on w
Mostly to fix the issue with Visual Studio and header files that was
introduced with CMake 2.6.3, I am working on 2.6.4. I have a release
candidate RC 6 that can be found here:
http://www.cmake.org/files/v2.6
(If there are no serious regressions, this is going to be 2.6.4
tomorrow, so PLEASE
On Mon, Apr 27, 2009 at 17:01, Bill Hoffman wrote:
> Tom Vercauteren wrote:
I just saw that when ctest is used to generate coverage information,
it looks for (gc)da files in the build directory - cf.
cmCTestCoverageHandler::FindGCovFiles in cmCTestCoverageHandler.cxx.
Hi Bill,
I bumped into this problem as well. We had several classes that were
compiled, but no methods in them were run. CTest ignored them and we didn't
have any coverage information on our dashboard. I would second this
recommendation to accumulate coverage based on what is compiled. As fa
Tom Vercauteren wrote:
I just saw that when ctest is used to generate coverage information,
it looks for (gc)da files in the build directory - cf.
cmCTestCoverageHandler::FindGCovFiles in cmCTestCoverageHandler.cxx.
If I understand it correctly, when everything is setup correctly for a
coverage
>> I just saw that when ctest is used to generate coverage information,
>> it looks for (gc)da files in the build directory - cf.
>> cmCTestCoverageHandler::FindGCovFiles in cmCTestCoverageHandler.cxx.
>>
>> If I understand it correctly, when everything is setup correctly for a
>> coverage build:
>
Tom Vercauteren wrote:
Hi All,
I just saw that when ctest is used to generate coverage information,
it looks for (gc)da files in the build directory - cf.
cmCTestCoverageHandler::FindGCovFiles in cmCTestCoverageHandler.cxx.
If I understand it correctly, when everything is setup correctly for a
Hi All,
I just saw that when ctest is used to generate coverage information,
it looks for (gc)da files in the build directory - cf.
cmCTestCoverageHandler::FindGCovFiles in cmCTestCoverageHandler.cxx.
If I understand it correctly, when everything is setup correctly for a
coverage build:
- gcc g
Dieter Oberkofler wrote:
I have been digging into this issue and found out that the problem might be
cause by the following command that might have changed it's behaviour in
CMake 2.6.4
==
SET(CMAKE_CXX_LINK_EXECUTABLE "link.exe /OUT: > .ler
${CMAKE_START_TEMP_FILE}
${CMAKE_END_TEMP_FI
Hi all,
I was wondering whether it's possible to somehow redefine an existing
target within a nested project. Let me give an example.
Suppose my CMake project has the following structure
bigproject
subproject_1
subproject_2
where bigproject, subproject_1 and subproject_2 are all CMake proje
Dieter Oberkofler wrote:
That should be:
D:\MyDev\ljs_app\trunk\tools\..\xvt\win\lib\tls12dvc71.lib
You are absolutely right but it seems to have worked in CMake 2.4.6...
http://www.cmake.org/cmake/help/cmake2.6docs.html#policy:CMP0008
http://www.cmake.org/cmake/help/cmake2.6docs.html#command
On Sun, Apr 26, 2009 at 11:14 PM, Alexander Neundorf <
a.neundorf-w...@gmx.net> wrote:
> On Friday 24 April 2009, Theodore Papadopoulo wrote:
> > Alexander Neundorf wrote:
> > > On Friday 24 April 2009, Theodore Papadopoulo wrote:
> > > As an experience, I have tried to mimick the gnu make check a
On Fri, Apr 24, 2009 at 8:07 PM, Richard Quirk wrote:
> On Fri, Apr 24, 2009 at 5:42 PM, Igor Karatayev wrote:
>> Hello.
>>
>> I am building my library for two different processors arm7 and arm9.
>> devkitArm requeres ARM7 or ARM9 macroses should be defined when
>> building for any processor. I t
Thnx it helps.
On Fri, Apr 24, 2009 at 7:53 PM, Denis Scherbakov
wrote:
>
>
> COMPILE_FLAGS in SET_TARGET_PROPERTIES will allow you to set per-target
> compile flags and definitions.
>
> Denis
>
>
>> I am building my library for two different processors arm7
>> and arm9.
>> devkitArm requeres AR
31 matches
Mail list logo
