Continue the lastest post of this article:
http://www.cmake.org/pipermail/cmake/2009-October/032615.html
On Tuesday 13 October 2009, Alexander Neundorf wrote:
> On Tuesday 13 October 2009, Naram Qashat wrote:
> Say I have a main executable and a number of shared libraries that rely on
> that exe
Attached is my initial attempt to check for the existence of python modules and
R packages.
In the case of python, I need to be able to check for a specific version of
python (find corresponding executable, libraries, and headers) and check for
modules in that version of python. This is not po
I am trying to add doxygen output to my installation package made via NSIS. I
want to allow the user to install the C++ API documentation. I would like the
install page of the NSIS wizard to look like:
Development
| C++ Headers
| Documentation
Runtime
| Libraries
Ri
On 06/11/2010 12:27 PM, Torri, Stephen CIV NSWCDD, W15 wrote:
From: Ryan Pavlik [mailto:rpav...@iastate.edu]
Sent: Fri 6/11/2010 1:16 PM
To: Torri, Stephen CIV NSWCDD, W15
Cc: cmake@cmake.org
Subject: Re: [CMake] How to install a shared library on a windows system
From: cmake-boun...@cmak
On 2010-06-10 22:24-0400 Bill Hoffman wrote:
GetShortPath calls GetShortPathName. From
http://bugs.winehq.org/show_bug.cgi?id=22286 it appears the point of
Clint's
patch was to eliminate a specific and well-known hash collision on Wine
caused by GetShortPathName, but from all the on-going uses o
On 06/11/2010 12:14 PM, Torri, Stephen CIV NSWCDD, W15 wrote:
From: cmake-boun...@cmake.org on behalf of Ryan Pavlik
Sent: Fri 6/11/2010 12:34 PM
To: cmake@cmake.org
Subject: Re: [CMake] How to install a shared library on a windows system
Stephen,
The catch is that windows searches for the DLL
> From: cmake-boun...@cmake.org on behalf of Ryan Pavlik
> Sent: Fri 6/11/2010 12:34 PM
> To: cmake@cmake.org
> Subject: Re: [CMake] How to install a shared library on a windows system
>
>
> Stephen,
>
> The catch is that windows searches for the DLL at runtime in specific
> locations: http://ms
Hi,
I am modifying the toolchain used to create a build on PlayStation 3 using
USER_MAKE_RULES_OVERRIDE variable. This setting is not taken into account in
the try_compile that cmake runs to verify the toolchain. This makes cmake fail
on linking because some windows specific link commands get
Thanks Michael, but for various reasons, I really don't want all the targets
ending up in the same bin directory. If that's the only way to solve it, then
I guess I'll do commands to copy the binaries for a test to a test only
directory.
I've tried looking at the target property RUNTIME_OUT
Stephen,
The catch is that windows searches for the DLL at runtime in specific
locations: http://msdn.microsoft.com/en-us/library/7d83bc18%28VS.80%29.aspx
This is why, when you do an install(TARGETS some-shared-libyou need
both the RUNTIME DESTINATION (for the dll) and the ARCHIVE DESTINA
I am running into a problem with a project that installs a shared library. The
files for the project are all places in the correct directories. What I am
finding is that when I compile a project with uses the shared library it
compiles and links correctly but the library is not found when the ex
> -Original Message-
> From: Michael Wild [mailto:them...@gmail.com]
> Sent: Friday, June 11, 2010 10:06 AM
> To: Hickel, Kelly
> Cc: cmake@cmake.org
> Subject: Re: [CMake] Best way to write add_test that depends on shared
> objects
>
>
> On 11. Jun, 2010, at 16:58 , Hickel, Kelly wrote:
On 11. Jun, 2010, at 16:58 , Hickel, Kelly wrote:
> I'm using CMake 2.8.1 and I want to write a simple test for one of the
> executable targets, but it failes because the shared libraries aren't in the
> directory or on the path.
>
> So, with something like the below, where bar and baz are sha
I'm using CMake 2.8.1 and I want to write a simple test for one of the
executable targets, but it failes because the shared libraries aren't in the
directory or on the path.
So, with something like the below, where bar and baz are shared objects built
by CMakeLists.txt files in other directorie
Thomas,
I made two changes to your proposed cmake file:
- include(FindPackageHandleStandardArgs)
- use a foreach to simplify the finding of executables
If this is ok with you I can update it on CMake/Modules
Ref:
http://gdcm.svn.sf.net/viewvc/gdcm/trunk/CMake/FindDCMTK.cmake?view=markup
Thanks
Ryan Pavlik wrote:
On 06/10/2010 03:28 PM, Thomas Sondergaard wrote:
The FindDCMTK.cmake module in the git master branch doesn't find all
the dcmtk libraries. I've attached a modified version of FindDCMTK
that finds all the dcmtk libraries. It is also about 25% smaller as
some duplicated code
On Friday, June 11, 2010, Martin Costabel wrote:
> -DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=""
> -DCMAKE_OSX_SYSROOT:PATH="/"
Hi Martin,
thanks for the pointer!
set (CMAKE_OSX_ARCHITECTURES "")
in the main CMakeLists.txt did the trick. Phew :)
Cheers
Daniel
___
On Fri, Jun 11, 2010 at 5:19 AM, Hugh Sorby wrote:
>
> To my knowledge the environment looks good in the properties/"C/C++ Make
> Project" page for my project. That is the PATH variable in the environment
> tab on this page contains the location of nmake on my system.
I'm afraid it's not enough
18 matches
Mail list logo
