Hi
I cannot make a small stand alone example, it is a big project.
however I have checked the cmakelists. I am sending you the part that is
responsible for making the cuda file lists.
On Thu, Jul 28, 2011 at 8:03 AM, Yuri Timenkov wrote:
> The original CMakeLists will be helpful to solve your p
I'm not sure I understood your question, but now I use ExternalProject (from
CMake 2.8.4) with Visual Studio 2010 which has 2 externals: one built with
custom command (the C# project) and the second one is CMake-based but with
VC6 generator. Everything compiles and works fine. But I don't have down
The original CMakeLists will be helpful to solve your problem. Could you
provide a small stand-alone example reproducing your problem?
On Wed, Jul 27, 2011 at 8:02 PM, Nima Nouri wrote:
> Hi everybody
>
> I am currently trying to compile my source code on VC9.
> Previously I was using VC8 and ev
Just as an alternative approach; instead of relying on having the code
in-place, generate appropriate install directives RUNTIME_, ARCHIVE_
and LIBRARY_ issues similar, needing basically a macro
my_install(target) if( WIN32) install( #what's correct for windows )
else( WIN32 ) install ( what's corr
Hi,
Is nobody on this list using CTK or Slicer with Visual Studio 2010 in
superbuild mode? If you do, could you please post if you had success or not?
Thanks,
Sascha
On 07/22/2011 06:20 PM, Jean-Christophe Fillion-Robin wrote:
Hi Folks,
Before digging further into the problem ... if some yo
You could set the target property RUNTIME_OUTPUT_DIRECTORY on your library
targets. That would override the CMAKE_RUNTIME_OUTPUT_DIRECTORY variable
just for those targets.
2011/7/27 Laura Autón García
> Hello Alan,
> Thank you very much for your answer.
> It woks perfectly using deprecated opti
2011/7/27 Bjørn Forsman :
> Hi all,
>
> I wonder if I've hit some bugs in the CPack generators, specifically
> TGZ and DEB. They do not behave as I expect them to. What I expect
> them to do is to generate an archive of files that look exactly like
> what 'make install' puts in DESTDIR. If this is
Hi all,
I wonder if I've hit some bugs in the CPack generators, specifically
TGZ and DEB. They do not behave as I expect them to. What I expect
them to do is to generate an archive of files that look exactly like
what 'make install' puts in DESTDIR. If this is a wrong assumption
then please tell m
2011/7/27 :
> Hi all,
>
> I tried to cross-compile an internal application for windows on a linux
> machine,
> but failed, because cmake at some point re-start the configure process, and
> drops the CMAKE_SYSTEM_NAME variable along that way. Attached is a
> minimal CMakeLists.txt, which reproduces
Hi all,
I tried to cross-compile an internal application for windows on a linux
machine,
but failed, because cmake at some point re-start the configure process,
and
drops the CMAKE_SYSTEM_NAME variable along that way. Attached is a
minimal CMakeLists.txt, which reproduces the problem.
Is there
On 27 July 2011 13:20, Maxime Lecourt wrote:
> Hi,
>
> is that a valid CMake instruction ?
> target_link_libraries(bt "-Wl,-whole-archive -L../idt/ -latidt
> -Wl,-no-whole-archive")
Yes, it certainly works.
> I thought you were supposed to use
> set_target_properties(bt PROPERTIES LINK_FLAGS
Hi,
is that a valid CMake instruction ?
target_link_libraries(bt "-Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive")
I thought you were supposed to use
set_target_properties(bt PROPERTIES LINK_FLAGS "-Wl,-whole-archive -L../idt/
-latidt -Wl,-no-whole-archive")
Maxime
2011/7/27 Sanata
On 27 July 2011 12:37, Rolf Eike Beer wrote:
>> include_directories(${at_SOURCE_DIR})
>> add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
>> target_link_libraries(atfwmath)
>
> You are telling CMake here that atfwmath should be linked against
> something. But you don't tell it aga
On 27 July 2011 12:33, Marcel Loose wrote:
> Hi Sanatan,
>
> If you didn't make any copy/paste errors, then I think you made a typo.
>
>> add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
>> :
>> :
>> target_link_libraries(bt atidt atmath boost_date_time
> boost_program_options)
>
> include_directories(${at_SOURCE_DIR})
> add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
> target_link_libraries(atfwmath)
You are telling CMake here that atfwmath should be linked against
something. But you don't tell it against what.
Eike
_
Hi Sanatan,
If you didn't make any copy/paste errors, then I think you made a typo.
> add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
> :
> :
> target_link_libraries(bt atidt atmath boost_date_time
boost_program_options)
See: atfwmath versus atmath. You should fix your add_libr
On Wed, 2011-07-27 at 12:14 +0100, Sanatan Rai wrote:
> Hi,
>This is a newbie question. So apologies in advance if this is
covered
> somewhere in the docs (I haven't been able to find a satisfactory
explanation).
>
> The issue is this:
>
> * I have a library called (lib)atmath as per:
>
> in
Hello Alan,
Thank you very much for your answer.
It woks perfectly using deprecated options, which is kind of funny,
isn't it? As Glenn pointed out in his reply afterwards, newer options
(ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY and
RUNTIME_OUTPUT_DIRECTORY) work differently from deprecat
Hi,
This is a newbie question. So apologies in advance if this is covered
somewhere in the docs (I haven't been able to find a satisfactory explanation).
The issue is this:
* I have a library called (lib)atmath as per:
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp R
Hello glenn,
Thank you for your answer.
I misunderstood the documentation. Thank you for pointing this out!
Documentation:
"...For DLL platforms the DLL part of a shared library is treated as a
runtime target and the corresponding import library is treated as an
archive target..."
It's a pity, be
> Have a look at the documentation for CMAKE_RUNTIME_OUTPUT_DIRECTORY. On
> Linux the .so shared library files do go in the LIBRARY_OUTPUT_DIRECTORY.
> However, on Windows the DLL files are placed in the runtime directory and
> only the import libraries (.LIB files) are placed in the
> LIBRARY_OUT
> Have a look at the documentation for CMAKE_RUNTIME_OUTPUT_DIRECTORY. On
> Linux the .so shared library files do go in the LIBRARY_OUTPUT_DIRECTORY.
> However, on Windows the DLL files are placed in the runtime directory and
> only the import libraries (.LIB files) are placed in the
> LIBRARY_OUT
> Yes I do:
>
> install(
> TARGETS GluonCore
> RUNTIME DESTINATION bin
> LIBRARY DESTINATION ${LIB_INSTALL_DIR}
> ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
> FRAMEWORK DESTINATION ${LIB_INSTALL_DIR}
> )
If all destinations point to the same place you don't need to set them all
exp
2011/7/27 Laszlo Papp :
> Hi Eric,
>
>> So the solution begins with DOT NOT USE ABSOLUTE INSTALL PATH,
>> give it a try and tell us how it goes.
>
> Thanks a lot for your answer. It has been very useful. The components
> seem much better for now after this change you were proposing:
> https://proje
24 matches
Mail list logo
