[cmake-developers] [CMake 0012363]: Single-line status+result messages (echo -n, \c)
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12363 == Reported By:Christopher Sean Morrison Assigned To: == Project:CMake Issue ID: 12363 Category: CMake Reproducibility:N/A Severity: feature Priority: normal Status: new == Date Submitted: 2011-07-27 14:43 EDT Last Modified: 2011-07-27 14:43 EDT == Summary:Single-line status+result messages (echo -n, \c) Description: CMake's simplified build reporting is great, but the ability to display the results of configuration testing seems very limited. Similar to autotools configuration testing, our CMake build tests various platform characteristics. Right now, the user is notified that a test is about to commence with message(STATUS, Testing feature blah) and then the result with another message(STATUS, Testing feature blah: failed). That of course annoyingly leads to two lines for every feature tested (which is hundreds of tests for a large complex package). It would be great if we could display that message in two parts, once before the test with a label, once after with the result. That is akin to echo -n Testing feature blah: echo failed or AC_MSG_CHECKING([feature blah]) AC_MSG_RESULT([failed]) in autotools/m4 parlance. For platforms/output configurations that can display them sequentially, you get nice pretty-printed output. For others (e.g., MSVC) where only single-line output is supported, you'd get that as either two lines or line-buffered until the result is ready. Additional Information: We could only print the latter message, but some tests take a while so preliminary feedback for environments where that is possible is highly desirable. I tried using the old '\c' character on message() but as you probably know, that reports it is an invalid escape sequence. == Issue History Date ModifiedUsername FieldChange == 2011-07-27 14:43 Christopher Sean MorrisonNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012364]: Report compilation line on error
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12364 == Reported By:Christopher Sean Morrison Assigned To: == Project:CMake Issue ID: 12364 Category: CMake Reproducibility:N/A Severity: feature Priority: high Status: new == Date Submitted: 2011-07-27 15:00 EDT Last Modified: 2011-07-27 15:00 EDT == Summary:Report compilation line on error Description: The vast majority of the time, the simplified neat output reporting (e.g., during a 'make' target build) from cmake is desirable, nay awesome. However, on those occasions where the compile fails, seeing the stderr output is often (if not usually) insufficient. Of course, make VERBOSE=1 will give all the gruesome detail including the compilation line, but I don't want verbose all the time or for a whole build pass. I just want the compilation line for the times the compiler fails. I'd propose capturing the command entire output and, if the command fails (i.e., non-zero exit status or something that would otherwise halt the build), printing the command followed by the buffered output. This could be made a feature only enabled when VERBOSE=0 or something that could be enabled project-wide with a cmake function if it's undesirable as default behavior. Thanks for your time and attention. == Issue History Date ModifiedUsername FieldChange == 2011-07-27 15:00 Christopher Sean MorrisonNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Lots of unnecessary search PATHS in FindGIF.cmake and FindFreetype.cmake ?
On Wednesday 27 July 2011, Eric Wing wrote:
On 7/26/11, Alexander Neundorf neund...@kde.org wrote:
Hi,
I just had a look at FindGIF.cmake and FindFreetype.cmake.
Both have similar code:
...
What about the two PATH_SUFFIXES lib64 and lib ? They shouldn't be
necessary.
Or, how is lib64 handled if I just give /some/dir/lib as argument to
PATHS ?
Is a lib64 version then checked too ? (I think no, but I'm not sure).
Most of those probably can be removed safely. Those modules were
written in another era when CMake had very little in the common core
and no Mac OS X Framework support.
That HKEY OSG_ROOT shouldn't be there. I don't know how that got snuck
in. I was advocating for generic things like $ENV{GIF_DIR}. But now
that it is there...I'm not sure about removing it.
/usr/freeware was added because I think I got complaints from IRIX and
Gentoo users?
I forgot which platforms used /usr/local/X11. (Does/did FreeBSD use this
one?)
Can you please give the FindGIFAndFreetypeCleanupAndEnhancements branch a try
?
http://cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/FindGIFAndFreetypeCleanupAndEnhancements
I removed the dirs which are IMO unnecessary.
What about ~/Library/Frameworks ?
Is this searched by default on OSX or not ?
If it works for you, I'll merge it into next then.
Alex
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Fwd: CPACK/NSIS: Subfolders/components related generation issue
2011/7/27 Laszlo Papp lp...@kde.org:
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://projects.kde.org/projects/playground/games/gluon/repository/revisions/master/entry/core/CMakeLists.txt#L19
The bin/share/include directories are generated properly inside each
component, but there is still some issue with the library part. There
are no DLLs generated inside the components and I do not know why. It
seems to me, like ${LIB_INSTALL_DIR} is properly used in the install
lines.
Any thought ?
Yes I do:
install(
TARGETS GluonCore
RUNTIME DESTINATION bin
LIBRARY DESTINATION ${LIB_INSTALL_DIR}
ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
FRAMEWORK DESTINATION ${LIB_INSTALL_DIR}
)
install(
TARGETS GluonAudio
RUNTIME DESTINATION bin
LIBRARY DESTINATION ${LIB_INSTALL_DIR}
ARCHIVE DESTINATION ${LIB_INSTALL_DIR}
FRAMEWORK DESTINATION ${LIB_INSTALL_DIR}
)
there is no COMPONENT specified at least for those two.
When something is install(...)ed without specifying a component then CMake put
them in the special Unspecified component which is builtin.
Now since you specify that you only want to package the following components:
#Component based settings
set(CPACK_COMPONENTS_ALL
gluoncore
gluonaudio
gluoninput
gluongraphics
gluonengine
gluonplayer
gluonqtplayer
gluoncreator
)
The Unspecified does not get packaged.
So the solution would be:
Verify ALL your install(...) statement in order to verify whether if
you specified the COMPONENT argument
and/or
add Unspecified to CPACK_COMPONENTS_ALL and check that this
component is empty.
--
Erk
Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Fwd: CPACK/NSIS: Subfolders/components related generation issue
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
explicitely, this should do the same:
install(
TARGETS GluonCore
RUNTIME DESTINATION bin
DESTINATION ${LIB_INSTALL_DIR}
)
Eike
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invalid library output directory when VC++ solution is generated
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_OUTPUT_DIRECTORY. The .lib files got into ARCHIVE_OUTPUT_DIRECTORY. Eike ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invalid library output directory when VC++ solution is generated
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_OUTPUT_DIRECTORY. The .lib files got into ARCHIVE_OUTPUT_DIRECTORY. Eike ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invalid library output directory when VC++ solution is generated
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, because our intention was to keep in Windows, the way
this is done in Linux, I mean, libraries (either shared or not) in
../lib directory and executables in ../bin directory. Right now, with
no other ideas than the one provided by Alan in his previous reply,
there seems to be no simple way to separate DLL files from binaries
ones. It works perfectly using deprecated options:
SET(EXECUTABLE_OUTPUT_PATH ${BIN_DIR} CACHE PATH Directory for
executables)
SET(LIBRARY_OUTPUT_PATH ${LIB_DIR} CACHE PATH
Directory for executables)
I understand this is not desirable, so we will have to make a choice
between using deprecated properties while we try to figure out other
way, or moving to the new way.
2011/7/26 Glenn Coombs glenn.coo...@gmail.com:
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_OUTPUT_DIRECTORY.
2011/7/25 Laura Autón García laura.au...@gmail.com
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR ${PROJECT_SOURCE_DIR}/lib)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH Directory
for libraries)
According to the documentation:
CMAKE_LIBRARY_OUTPUT_DIRECTORY: Where to put all the LIBRARY
targets when built.
This variable is used to initialize the LIBRARY_OUTPUT_DIRECTORY
property on all the targets.
See that target property for additional information.
Also, the documentation regarding LIBRARY_OUTPUT_DIRECTORY shows:
LIBRARY_OUTPUT_DIRECTORY: Output directory in which to build
LIBRARY target files.
This property specifies the directory into which library target
files should be built. There are three
kinds of target files that may be built: archive, library, and
runtime. Executables are always treated
as runtime targets. Static libraries are always treated as archive
targets. Module libraries are always
treated as library targets. For non-DLL platforms shared libraries
are treated as library targets. 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. All Windows-based
systems including Cygwin are
DLL platforms. This property is initialized by the value of the variable
CMAKE_LIBRARY_OUTPUT_DIRECTORY if it is set when a target is created.
However, when the project is generated, the library output directory
is not the one specified, but the one I mentioned above.
If anyone has any idea why this may be happening, it would be appreciated.
The binaries, on the other hand, as generated in their correct directory.
Thank you in advance.
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Linking problem
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 RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
Where coin.hpp:
#ifndef COIN_HPP_INCLUDED
#define COIN_HPP_INCLUDED
#include sstream
#include fw/math/RngStream.h
using namespace std;
class coin
{
private:
static string name()
{
static unsigned long id(0);
stringstream str;
str Coin_ (++id) _stream;
return str.str();
}
double p;
RngStream *rng;
void init();
public:
coin();
coin(double _p);
~coin();
bool toss();
void reset(double _p);
};
#endif
and coin.cpp:
#include fw/math/coin.hpp
coin::coin() : p(0.5), rng(0) { init();}
coin::coin(double _p) : p(_p), rng(0)
{
if ((p 0) || (p 1))
throw;
init();
}
coin::~coin()
{
delete rng, rng = 0;
}
void coin::init()
{
rng = new RngStream(name().c_str());
}
bool coin::toss()
{
double u(rng-RandU01());
return (u = p);
}
void coin::reset(double _p)
{
if ((_p 0) || (_p 1)) throw;
p = _p;
}
I use these classes in another library:
add_library(atidt STATIC idt.cpp)
target_link_libraries(atidt atmath boost_date_time boost_signals)
which is then linked to the final executable:
add_executable(bt bt.cpp)
target_link_libraries(bt atidt atmath boost_date_time boost_program_options)
target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive)
When I run make:
* libatmath compiles fine.
* libatidt complies fine.
* when compiling bt, it complains about coin::coin, coin::reset etc
being undefined.
Ie it would see it is not finding them in the linked libraries.
Even though:
$ ar t libatmath.a
RngStream.cpp.o
coin.cpp.o
What am I missing here? It is also quite bizarre as it doesn't
complain about the declarations in
RngStream.h which are defined in RngStream.c.
Thanks in advance!
--Sanatan
--
Sanatan Rai
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invalid library output directory when VC++ solution is generated
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 deprecated ones, as in
Windows, shared libraries are generated in the runtime directory
instead of the library directory. And static libraries are even
generated in the archive output directory instead of library
directory:
Executables are always treated as runtime targets. -- Static
libraries are always treated as archive targets ---. Module libraries
are always treated as library targets. -- For non-DLL platforms
shared libraries are treated as library targets -- (that's why it
works as expected in Linux). -- 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. All
Windows-based systems including Cygwin are DLL platforms.
By the way, we build shared libraries after our project solution is
generated. I mean, we first generate with CMake the solution to be
opened in Visual C++ and then we compile the solution in Visual C++.
At the point of compilation, the dll library is generated. So that,
there is no conflict between when we determine where the dll is to be
generated and when is generated.
I am not really experienced with CMake tool, but it seems their
developers had their reasons to determine that dll's have to be
generated in the runtime directory rather than library one. That's not
what we want though. We may accept the changes unless we figure out
other way to do it.
2011/7/25 Alan W. Irwin ir...@beluga.phys.uvic.ca:
On 2011-07-25 12:19+0100 Laura Autón García wrote:
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR ${PROJECT_SOURCE_DIR}/lib)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH Directory
for libraries)
One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
after your dll's are built.
Just in case that is not the source of the problem, here is
some further discussion.
I cannot spot anything wrong with your command above. However, our
project (PLplot) hasn't tried that recommended variable yet. Instead
we use the deprecated LIBRARY_OUTPUT_PATH variable (mentioned in the
documentation) like the following (because we are a cross-platform
project):
# in windows all created dlls are gathered in the dll directory
# if you add this directory to your PATH all shared libraries are
available
if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
This works on Windows according to others, and I have also
personally verified that it works under Wine.
Although a different variable is used, note the differences with
how that variable is set with your case.
(1) The subdirectory is in the build tree rather than the source
tree.
(2) We don't cache the variable.
I don't think any of these differences should matter in terms of
whether the functionality works or not, but you might want to try them
with CMAKE_LIBRARY_OUTPUT_DIRECTORY just in case that might be the
source of your difficulty. You could also set LIBRARY_OUTPUT_PATH
like we do as a test, but it would be better to figure out how to get
CMAKE_LIBRARY_OUTPUT_DIRECTORY to work correctly since our approach is
deprecated. (It wasn't deprecated when we started using CMake years
ago, and we plan to switch over to the recommended method at some point.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__
Linux-powered Science
__
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep
Re: [CMake] Linking problem
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:
include_directories(${at_SOURCE_DIR})
add_library(atfwmath RngStream.cpp RngStream.h coin.cpp coin.hpp)
target_link_libraries(atfwmath)
Where coin.hpp:
#ifndef COIN_HPP_INCLUDED
#define COIN_HPP_INCLUDED
#include sstream
#include fw/math/RngStream.h
using namespace std;
class coin
{
private:
static string name()
{
static unsigned long id(0);
stringstream str;
str Coin_ (++id) _stream;
return str.str();
}
double p;
RngStream *rng;
void init();
public:
coin();
coin(double _p);
~coin();
bool toss();
void reset(double _p);
};
#endif
and coin.cpp:
#include fw/math/coin.hpp
coin::coin() : p(0.5), rng(0) { init();}
coin::coin(double _p) : p(_p), rng(0)
{
if ((p 0) || (p 1))
throw;
init();
}
coin::~coin()
{
delete rng, rng = 0;
}
void coin::init()
{
rng = new RngStream(name().c_str());
}
bool coin::toss()
{
double u(rng-RandU01());
return (u = p);
}
void coin::reset(double _p)
{
if ((_p 0) || (_p 1)) throw;
p = _p;
}
I use these classes in another library:
add_library(atidt STATIC idt.cpp)
target_link_libraries(atidt atmath boost_date_time boost_signals)
which is then linked to the final executable:
add_executable(bt bt.cpp)
target_link_libraries(bt atidt atmath boost_date_time
boost_program_options)
target_link_libraries(bt -Wl,-whole-archive -L../idt/ -latidt
-Wl,-no-whole-archive)
When I run make:
* libatmath compiles fine.
* libatidt complies fine.
* when compiling bt, it complains about coin::coin, coin::reset etc
being undefined.
Ie it would see it is not finding them in the linked libraries.
Even though:
$ ar t libatmath.a
RngStream.cpp.o
coin.cpp.o
What am I missing here? It is also quite bizarre as it doesn't
complain about the declarations in
RngStream.h which are defined in RngStream.c.
Thanks in advance!
--Sanatan
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
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_library() line. Best regards, Marcel Loose. ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
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
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 27 July 2011 12:33, Marcel Loose lo...@astron.nl 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) See: atfwmath versus atmath. You should fix your add_library() line. Sorry, I typed the example in, so that's just a typo. There's no typo in the original CMakeLists.txt files. -- Sanatan Rai ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 27 July 2011 12:37, Rolf Eike Beer e...@sf-mail.de 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 against what.
There are no other dependencies. Originally, this line was not there.
I added it to see if it would fix the problem.
--
Sanatan Rai
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
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 Sanatan Rai sana...@gmail.com
On 27 July 2011 12:37, Rolf Eike Beer e...@sf-mail.de 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 against what.
There are no other dependencies. Originally, this line was not there.
I added it to see if it would fix the problem.
--
Sanatan Rai
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Linking problem
On 27 July 2011 13:20, Maxime Lecourt maxime.leco...@gmail.com 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 -Wl,-whole-archive -L../idt/ -latidt -Wl,-no-whole-archive) Thanks for the pointer. -- Sanatan Rai ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Cross Compiling with cmake 2.8.5
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 a way to avoid the reconfiguration?
TIA
R. Czerny
Console output:
someone@debian-vm:~/cross/build$ cmake -DCMAKE_SYSTEM_NAME=Windows
-DCMAKE_C_COMPILER=i586-mingw32msvc-gcc
-DCMAKE_RC_COMPILER=i586-mingw32msvc-windres ..
-- The C compiler identification is GNU
-- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc
-- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CC=TRUE CSN=Windows
-- Configuring done
You have changed variables that require your cache to be deleted.
Configure will be re-run and you may have to reset some variables.
The following variables have changed:
CMAKE_RC_COMPILER= i586-mingw32msvc-windres
-- The C compiler identification is GNU
-- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc
-- Check for working C compiler: /usr/bin/i586-mingw32msvc-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- CC=FALSE CSN=Linux
-- Configuring done
-- Generating done
-- Build files have been written to: /home/czerny/Quellen/hospec/foo/foo
cmake_minimum_required(VERSION 2.8)
project(foo C)
message(STATUS CC=${CMAKE_CROSSCOMPILING} CSN=${CMAKE_SYSTEM_NAME})
add_executable(fo foo.c)
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Cross Compiling with cmake 2.8.5
2011/7/27 r.cze...@esa-grimma.de: 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 a way to avoid the reconfiguration? TIA R. Czerny Console output: someone@debian-vm:~/cross/build$ cmake -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_C_COMPILER=i586-mingw32msvc-gcc -DCMAKE_RC_COMPILER=i586-mingw32msvc-windres .. Did you read this http://www.cmake.org/Wiki/CMake_Cross_Compiling and if yes why didn't you use a toolchain file? -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Buggy CPack generator behaviour?
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 me.
So based on that assumption, here are the issues:
1. TGZ doesn't populate the archive with all needed parent
directories. A binary that 'make install' puts in
DESTDIR/usr/local/bin is put in archive_root/bin with TGZ. I would
have expected the archive to contain archive_root/usr/local/bin
(like the DEB generator does). Is there maybe a configuration option
for this?
2. TGZ fails on absolute DESTINATION paths:
CMake Error at /home/bjornfor/eraseme/build/cmake_install.cmake:44 (FILE):
file INSTALL cannot copy file /home/bjornfor/eraseme/build/hello to
/usr/bin/hello.
(And no, I don't want to run as root just to create an archive. If DEB
can handle this so should TGZ.)
3. DEB won't generate a .deb with binaries in /usr/local/bin. Example:
set CMAKE_INSTALL_PREFIX=/usr/local and install(TARGETS hello
DESTINATION bin). 'make install' puts hello in /usr/local/bin but the
.deb contains /usr/bin/hello (missing 'local').
Maybe the last issue is by design because no packaged software should
install to /usr/local. But wouldn't it be nicer if cpack either (1)
tell users that it changed some paths, (2) error out and die or (3) be
stupid and allow it?
Can anyone help me with this? Or better yet, fix it? :-)
Here is a script I've been using for playing with these issues:
### begin terminal session ###
topdir=$(pwd)
mkdir eraseme || { echo Directory exists, aborting.; exit 1; }
cd eraseme
cat EOF hello.c
#include stdio.h
int main()
{
printf(Hello world\n);
return 0;
}
EOF
mkdir etc
cat EOF etc/myconfigfile
# empty
EOF
cat EOF CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
add_executable(hello hello.c)
install(TARGETS hello DESTINATION bin)
set(SYSCONFDIR \${CMAKE_INSTALL_PREFIX}/etc CACHE PATH Location for
system configuration files)
set(CPACK_PACKAGE_CONTACT me@localhost.local)
set(CPACK_GENERATOR DEB;TGZ)
set(CPACK_INCLUDE_TOPLEVEL_DIRECTORY 0)
# TGZ generator crashes on absolute paths, DEB doesn't
#install(DIRECTORY etc/ DESTINATION \${SYSCONFDIR})
install(DIRECTORY etc/ DESTINATION .)
include(CPack)
EOF
mkdir build
cd build
cmake ..
make install DESTDIR=${topdir}/eraseme/destdir
make package
echo
echo Install tree:
#ls -lR $topdir/eraseme/destdir
tree $topdir/eraseme/destdir
echo
echo Contents of DEB:
ar -x Project-0.1.1-Linux.deb
tar tf data.tar.gz
echo
echo Contents of TGZ:
tar tf Project-0.1.1-Linux.tar.gz
cd $topdir
### end terminal session ###
Best regards,
Bjørn Forsman
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Buggy CPack generator behaviour?
2011/7/27 Bjørn Forsman bjorn.fors...@gmail.com: 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 me. This is a wrong assumption for several reasons but keep reading. I'll try to answer inline, for the part I do have answer :-] So based on that assumption, here are the issues: 1. TGZ doesn't populate the archive with all needed parent directories. A binary that 'make install' puts in DESTDIR/usr/local/bin is put in archive_root/bin with TGZ. I would have expected the archive to contain archive_root/usr/local/bin (like the DEB generator does). Is there maybe a configuration option for this? CPack does not use CMAKE_INSTALL_PREFIX but CPACK_PACKAGING_INSTALL_PREFIX if this variable is not defined, each CPack generator has an historical builtin value which is used. ArchiveGenerator (TGZ, ZIP, TBZ2 etc...) are using none RPM has /usr DEB has /usr if you do cpack -D CPACK_PACKAGING_INSTALL_PREFIX=/usr/local -G TGZ then you may get the wanted prefix in TGZ. 2. TGZ fails on absolute DESTINATION paths: CMake Error at /home/bjornfor/eraseme/build/cmake_install.cmake:44 (FILE): file INSTALL cannot copy file /home/bjornfor/eraseme/build/hello to /usr/bin/hello. I see you point. TGZ may handle absolute install path if you set(CPACK_SET_DESTDIR ON) i.e. cpack -D CPACK_SET_DESTDIR=ON -G TGZ will make TGZ tolerate absolute install path. (And no, I don't want to run as root just to create an archive. If DEB can handle this so should TGZ.) DEB (and RPM) internally set CPACK_SET_DESTDIR to ON (in fact I_ON) This is not the default behavior for archive generators mainly for backward-compatibility reason, and other reason I cannot remember but you should find a lengthly discussion about that on some closed bug on the bug tracker. I may dig this if you want the precise ref. 3. DEB won't generate a .deb with binaries in /usr/local/bin. Example: set CMAKE_INSTALL_PREFIX=/usr/local and install(TARGETS hello DESTINATION bin). 'make install' puts hello in /usr/local/bin but the .deb contains /usr/bin/hello (missing 'local'). Same as 1) use CPACK_PACKAGING_INSTALL_PREFIX, this is a feature not a bug. Maybe the last issue is by design because no packaged software should install to /usr/local. But wouldn't it be nicer if cpack either (1) tell users that it changed some paths, (2) error out and die or (3) be stupid and allow it? Can anyone help me with this? Or better yet, fix it? :-) I agree that some CPack generators behavior discrepancies are puzzling at first but making it more coherent is difficult without breaking backward compatibility. Unless I'm wrong there is nothing to fix here but the CPack documentation, for which patches are welcome as well. See the discussion here: http://public.kitware.com/Bug/view.php?id=10067 And the may be sparse but existing doc on the Wiki: http://www.cmake.org/Wiki/CMake#CPack If you want to do some specific adjustment depending on the CPack generator used you may use a CPACK_PROJECT_CONFIG_FILE see doc here: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 I hope this helps. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invalid library output directory when VC++ solution is generated
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 laura.au...@gmail.com
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 deprecated ones, as in
Windows, shared libraries are generated in the runtime directory
instead of the library directory. And static libraries are even
generated in the archive output directory instead of library
directory:
Executables are always treated as runtime targets. -- Static
libraries are always treated as archive targets ---. Module libraries
are always treated as library targets. -- For non-DLL platforms
shared libraries are treated as library targets -- (that's why it
works as expected in Linux). -- 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. All
Windows-based systems including Cygwin are DLL platforms.
By the way, we build shared libraries after our project solution is
generated. I mean, we first generate with CMake the solution to be
opened in Visual C++ and then we compile the solution in Visual C++.
At the point of compilation, the dll library is generated. So that,
there is no conflict between when we determine where the dll is to be
generated and when is generated.
I am not really experienced with CMake tool, but it seems their
developers had their reasons to determine that dll's have to be
generated in the runtime directory rather than library one. That's not
what we want though. We may accept the changes unless we figure out
other way to do it.
2011/7/25 Alan W. Irwin ir...@beluga.phys.uvic.ca:
On 2011-07-25 12:19+0100 Laura Autón García wrote:
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR ${PROJECT_SOURCE_DIR}/lib)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH Directory
for libraries)
One possibility is you are setting CMAKE_LIBRARY_OUTPUT_DIRECTORY
after your dll's are built.
Just in case that is not the source of the problem, here is
some further discussion.
I cannot spot anything wrong with your command above. However, our
project (PLplot) hasn't tried that recommended variable yet. Instead
we use the deprecated LIBRARY_OUTPUT_PATH variable (mentioned in the
documentation) like the following (because we are a cross-platform
project):
# in windows all created dlls are gathered in the dll directory
# if you add this directory to your PATH all shared libraries are
available
if(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
set(LIBRARY_OUTPUT_PATH ${CMAKE_CURRENT_BINARY_DIR}/dll)
endif(BUILD_SHARED_LIBS AND WIN32 AND NOT CYGWIN)
This works on Windows according to others, and I have also
personally verified that it works under Wine.
Although a different variable is used, note the differences with
how that variable is set with your case.
(1) The subdirectory is in the build tree rather than the source
tree.
(2) We don't cache the variable.
I don't think any of these differences should matter in terms of
whether the functionality works or not, but you might want to try them
with CMAKE_LIBRARY_OUTPUT_DIRECTORY just in case that might be the
source of your difficulty. You could also set LIBRARY_OUTPUT_PATH
like we do as a test, but it would be better to figure out how to get
CMAKE_LIBRARY_OUTPUT_DIRECTORY to work correctly since our approach is
deprecated. (It wasn't deprecated when we started using CMake years
ago, and we plan to switch over to the recommended method at some point.)
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and
Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting
software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads
of
Linux Links project
Re: [CMake] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support
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 your experience issue with VS2010 and superbuild .. would be great if you could provide more details about your investigation. Thanks Jc -- Forwarded message -- From: *Sascha Zelzer* s.zel...@dkfz-heidelberg.de mailto:s.zel...@dkfz-heidelberg.de Date: Fri, Jul 22, 2011 at 12:07 PM Subject: Re: [Ctk-developers] VS2010 support To: ctk-develop...@commontk.org mailto:ctk-develop...@commontk.org Hi, there is something very strange going on. The generated VS 2010 projects (I am using the Express editions, 32bit) for the external dependencies like DCMTK, Log4Qt, etc. only call the download step of the ExternalProject_add call in our superbuild scripts. The projects are not configured and build. Did anybody experience the same? I tried with and without the VS 2010 SP1 and with CMake 2.8.4 and 2.8.5. Thanks, Sascha On 07/22/2011 01:39 PM, Sascha Zelzer wrote: Hi Folks, I would like to get Visual Studio 2010 compatibility for CTK. Currently, it looks like I will have to copy ExternalProject.cmake to CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small modifications should do. Any other ideas or objections? Thanks, Sascha ___ Ctk-developers mailing list ctk-develop...@commontk.org mailto:ctk-develop...@commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers ___ Ctk-developers mailing list ctk-develop...@commontk.org mailto:ctk-develop...@commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Invalid library output directory when VC++ solution is generated
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 correct for other systems )... but
anyhow, then with a few more lines, you can use cpack to generate
installers.
Now, this means you can't just 'Set Active Project' and click F5 to
run it, but you can right-click on the project, set the debugging
properties of 'Target executable(?)'(first line) (there's a browse if
you click the drop arrow), and then copy the path part of that and
copy-paste to start-in directory(third line). Then you can run it,
without having to force the solution/project outputs to a specific
place.
2011/7/25 Laura Autón García laura.au...@gmail.com:
Hello all,
In the project I am collaborating on, CMake is used in Windows in
order to generate a Visual C++ solution to be compiled afterwards. In
this process, everything seems to work fine as the external
directories and libraries are well included and everything compiles
and so. However, we are experiencing problems with the directory in
which our dll library is to be created.
We specify in CMake that the directory is ../lib but
when checking the configuration in Visual C++ software, it seems to be
../bin/Release directory, so the library is generated there.
The CMake sentences we wrote regarding this issue are as follows:
SET(LIB_DIR ${PROJECT_SOURCE_DIR}/lib)
SET(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${LIB_DIR} CACHE PATH Directory
for libraries)
According to the documentation:
CMAKE_LIBRARY_OUTPUT_DIRECTORY: Where to put all the LIBRARY
targets when built.
This variable is used to initialize the LIBRARY_OUTPUT_DIRECTORY
property on all the targets.
See that target property for additional information.
Also, the documentation regarding LIBRARY_OUTPUT_DIRECTORY shows:
LIBRARY_OUTPUT_DIRECTORY: Output directory in which to build
LIBRARY target files.
This property specifies the directory into which library target
files should be built. There are three
kinds of target files that may be built: archive, library, and
runtime. Executables are always treated
as runtime targets. Static libraries are always treated as archive
targets. Module libraries are always
treated as library targets. For non-DLL platforms shared libraries
are treated as library targets. 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. All Windows-based
systems including Cygwin are
DLL platforms. This property is initialized by the value of the variable
CMAKE_LIBRARY_OUTPUT_DIRECTORY if it is set when a target is created.
However, when the project is generated, the library output directory
is not the one specified, but the one I mentioned above.
If anyone has any idea why this may be happening, it would be appreciated.
The binaries, on the other hand, as generated in their correct directory.
Thank you in advance.
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem making vc project
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 nouri.f.n...@gmail.com wrote: Hi everybody I am currently trying to compile my source code on VC9. Previously I was using VC8 and every thing was fine but now cmake does make everything like before but only a vcproject file. I have attached both files in a rar archive to this mail, the one made for VC8 is larger 250KB and the one made for VC9 is the smaller 70KB. if you comparison the files (of course with a comparison utility like the ones notepad++ have) you will find that all cuda source files are not added to the build list on the VC9 file. Does any one has any idea about whats causing this? and How i can fix it? I should add that the settings of the cmake files for both VC8 and VC9 are set using the cmake internal parameters MSVC80 and MSVC90 and the configurations are the same. for example if (MSVC80) -The block of command endif (MSVC80) if (MSVC90) -The same block of command endif (MSVC90) -- Best Regards N.Nouri Ph.D Student Department of Mechanical Engineering Isfahan University of Technology Isfahan, Iran ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] VS2010 and superbuild - Fwd: [Ctk-developers] VS2010 support
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 download step - everything is in my source directory. The only wish I have I filed to Mantis: http://public.kitware.com/Bug/view.php?id=12322 Regards, Yuri On Thu, Jul 28, 2011 at 12:37 AM, Sascha Zelzer s.zel...@dkfz-heidelberg.de wrote: ** 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 your experience issue with VS2010 and superbuild .. would be great if you could provide more details about your investigation. Thanks Jc -- Forwarded message -- From: Sascha Zelzer s.zel...@dkfz-heidelberg.de Date: Fri, Jul 22, 2011 at 12:07 PM Subject: Re: [Ctk-developers] VS2010 support To: ctk-develop...@commontk.org Hi, there is something very strange going on. The generated VS 2010 projects (I am using the Express editions, 32bit) for the external dependencies like DCMTK, Log4Qt, etc. only call the download step of the ExternalProject_add call in our superbuild scripts. The projects are not configured and build. Did anybody experience the same? I tried with and without the VS 2010 SP1 and with CMake 2.8.4 and 2.8.5. Thanks, Sascha On 07/22/2011 01:39 PM, Sascha Zelzer wrote: Hi Folks, I would like to get Visual Studio 2010 compatibility for CTK. Currently, it looks like I will have to copy ExternalProject.cmake to CTK for the CMAKE_CACHE_ARGS argument. Then a couple of small modifications should do. Any other ideas or objections? Thanks, Sascha ___ Ctk-developers mailing list ctk-develop...@commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers ___ Ctk-developers mailing list ctk-develop...@commontk.org http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers -- +1 919 869 8849 ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ 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://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Problem making vc project
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 y...@timenkov.ru wrote:
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 nouri.f.n...@gmail.comwrote:
Hi everybody
I am currently trying to compile my source code on VC9.
Previously I was using VC8 and every thing was fine but now cmake does
make everything like before but only a vcproject file.
I have attached both files in a rar archive to this mail, the one made for
VC8 is larger 250KB and the one made for VC9 is the smaller 70KB.
if you comparison the files (of course with a comparison utility like the
ones notepad++ have) you will find that all cuda source files are not added
to the build list on the VC9 file.
Does any one has any idea about whats causing this? and How i can fix it?
I should add that the settings of the cmake files for both VC8 and VC9 are
set using the cmake internal parameters MSVC80 and MSVC90 and the
configurations are the same. for example
if (MSVC80)
-The block of command
endif (MSVC80)
if (MSVC90)
-The same block of command
endif (MSVC90)
--
Best Regards
N.Nouri
Ph.D Student
Department of Mechanical Engineering
Isfahan University of Technology
Isfahan, Iran
___
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://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Best Regards
N.Nouri
Ph.D Student
Department of Mechanical Engineering
Isfahan University of Technology
Isfahan, Iran
gpiutmd.iut.ac.ir
gpiutmd.webs.com
## $Id: CMakeLists.txt 2710 2010-02-08 15:44:07Z Nima $
## $URL: $
# Maintainer: Nima
#
macro(add_libGPIUTMD_source_dir dir)
add_subdirectory(${dir})
# find all source files in this directory
file(GLOB SRCS ${CMAKE_CURRENT_SOURCE_DIR}/${dir}/*.cc)
file(GLOB CU_SRCS ${CMAKE_CURRENT_SOURCE_DIR}/${dir}/*.cu)
file(GLOB HDRS ${CMAKE_CURRENT_SOURCE_DIR}/${dir}/*.h
${CMAKE_CURRENT_SOURCE_DIR}/${dir}/*.cuh)
# add them to the source group
source_group(${dir} FILES ${CU_SRCS} ${SRCS} ${HDRS})
# add them to the main libGPIUTMD list
list(APPEND _libGPIUTMD_sources ${SRCS} ${HDRS})
list(APPEND _libGPIUTMD_cu_sources ${CU_SRCS})
endmacro(add_libGPIUTMD_source_dir)
#
set(_libGPIUTMD_sources )
set(_libGPIUTMD_cu_sources )
# process all subdirectories, which add source files to _libGPIUTMD_sources and
_libGPIUTMD_cu_sources
set(_dir_list analyzers computes data_structures extern potentials python
system updaters utils)
if (ENABLE_CUDA)
list(APPEND _dir_list computes_gpu cuda updaters_gpu)
endif (ENABLE_CUDA)
foreach (dir ${_dir_list})
add_libGPIUTMD_source_dir(${dir})
endforeach (dir)
if (ENABLE_CUDA)
if (BUILD_SHARED_LIBS)
set (_libGPIUTMD_shared SHARED)
endif (BUILD_SHARED_LIBS)
CUDA_COMPILE(_CUDA_GENERATED_FILES ${_libGPIUTMD_cu_sources} OPTIONS
${CUDA_ADDITIONAL_OPTIONS} ${_libGPIUTMD_shared})
source_group(cuda_generated FILES ${_CUDA_GENERATED_FILES})
endif (ENABLE_CUDA)
add_library (libGPIUTMD ${_libGPIUTMD_sources} ${_CUDA_GENERATED_FILES})
##
# change the name of the library if it is dynamic
if (NOT ENABLE_STATIC)
# link the library to its dependancies
target_link_libraries(libGPIUTMD ${GPIUTMD_COMMON_LIBS})
# tweak the properties of the output to make a functional python module
set_target_properties(libGPIUTMD PROPERTIES PREFIX OUTPUT_NAME GPIUTMD)
# .dylib is not regognized as a python module by python on Mac OS X
if(APPLE)
set_target_properties(libGPIUTMD PROPERTIES SUFFIX .so)
endif(APPLE)
fix_cudart_rpath(libGPIUTMD)
# set the rpath so that the lib can find other libs stashed in lib/GPIUTMD
#set_target_properties(libGPIUTMD PROPERTIES INSTALL_RPATH
\\\$ORIGIN/../../GPIUTMD)
if (ENABLE_EMBED_CUDA)
set_target_properties(libGPIUTMD PROPERTIES INSTALL_RPATH
${CMAKE_INSTALL_PREFIX}/${LIB_INSTALL_DIR})
endif (ENABLE_EMBED_CUDA)
# for non-app-bundle relocatable installs, set the install name of the lib
for linking relative to bin/
if (NOT ENABLE_APP_BUNDLE_INSTALL)
set_target_properties(libGPIUTMD PROPERTIES INSTALL_NAME_DIR
@executable_path/../lib/GPIUTMD/python-module)
endif (NOT ENABLE_APP_BUNDLE_INSTALL)
endif (NOT ENABLE_STATIC)
if (ENABLE_STATIC)
# change the library name to something more sensible
if (WIN32)
set_target_properties(libGPIUTMD PROPERTIES OUTPUT_NAME libGPIUTMD)
else(WIN32)
set_target_properties(libGPIUTMD
[Cmake-commits] CMake branch, next, updated. v2.8.5-1311-g3a86ea6
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 3a86ea655d51b861ce00309fecdcfcb02946ec83 (commit)
via ea1696e9ab941cf74e9df8ce25de7c771af03adb (commit)
via f5ac6fa5b740d7f50bc5f93fadb5b06732b886fa (commit)
from a16c9a903900dce8239f71a9b261321bcaa32935 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a86ea655d51b861ce00309fecdcfcb02946ec83
commit 3a86ea655d51b861ce00309fecdcfcb02946ec83
Merge: a16c9a9 ea1696e
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 27 09:04:44 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 27 09:04:44 2011 -0400
Merge topic 'split-stdout-stderr' into next
ea1696e RunSingleCommand: Add a OUTPUT_NORMAL flag.
f5ac6fa RunSingleCommand: Replace verbose boolean with enum
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea1696e9ab941cf74e9df8ce25de7c771af03adb
commit ea1696e9ab941cf74e9df8ce25de7c771af03adb
Author: Johan Björk p...@spotify.com
AuthorDate: Tue Jul 26 09:36:40 2011 +0200
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 27 08:51:09 2011 -0400
RunSingleCommand: Add a OUTPUT_NORMAL flag.
OUTPUT_NORMAL does no processing of the output streams, it just passes
them through the same streams as they were received on.
diff --git a/Source/cmSystemTools.cxx b/Source/cmSystemTools.cxx
index 0b024a6..0f0e1b2 100644
--- a/Source/cmSystemTools.cxx
+++ b/Source/cmSystemTools.cxx
@@ -247,6 +247,12 @@ void cmSystemTools::Stdout(const char* s)
}
}
+void cmSystemTools::Stderr(const char* s, int length)
+{
+std::cerr.write(s, length);
+std::cerr.flush();
+}
+
void cmSystemTools::Stdout(const char* s, int length)
{
if(s_StdoutCallback)
@@ -634,9 +640,20 @@ bool
cmSystemTools::RunSingleCommand(std::vectorcmStdStringconst command,
{
cmSystemTools::Stdout(data, length);
}
+ else
+{
+ if(pipe == cmsysProcess_Pipe_STDERR)
+{
+ cmSystemTools::Stderr(data, length);
+}
+ else if(pipe == cmsysProcess_Pipe_STDOUT)
+{
+ cmSystemTools::Stdout(data, length);
+}
+ }
+}
}
}
- }
cmsysProcess_WaitForExit(cp, 0);
if ( output tempOutput.begin() != tempOutput.end())
{
diff --git a/Source/cmSystemTools.h b/Source/cmSystemTools.h
index b64d7ae..e95e1ba 100644
--- a/Source/cmSystemTools.h
+++ b/Source/cmSystemTools.h
@@ -75,6 +75,9 @@ public:
typedef void (*StdoutCallback)(const char*, int length, void*);
static void SetStdoutCallback(StdoutCallback, void* clientData=0);
+ ///! Send a string to stderr. Stdout callbacks will not be invoced.
+ static void Stderr(const char* s, int length);
+
///! Return true if there was an error at any point.
static bool GetErrorOccuredFlag()
{
@@ -196,7 +199,8 @@ public:
* Output is controlled with outputflag. If outputflag is OUTPUT_NONE, no
* user-viewable output from the program being run will be generated.
* OUTPUT_MERGE is the legacy behaviour where stdout and stderr are merged
- * into stdout.
+ * into stdout. OUTPUT_NORMAL passes through the output to stdout/stderr as
+ * it was received.
*
* If timeout is specified, the command will be terminated after
* timeout expires. Timeout is specified in seconds.
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index 3473d91..137665d 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -4296,7 +4296,8 @@ int cmake::Build(const std::string dir,
const std::string target,
const std::string config,
const std::vectorstd::string nativeOptions,
- bool clean)
+ bool clean,
+ cmSystemTools::OutputOption outputflag)
{
if(!cmSystemTools::FileIsDirectory(dir.c_str()))
{
@@ -4338,8 +4339,7 @@ int cmake::Build(const std::string dir,
projName.c_str(), target.c_str(),
output,
makeProgram.c_str(),
-config.c_str(), clean, false, 0,
-cmSystemTools::OUTPUT_MERGE,
+config.c_str(), clean, false, 0, outputflag,
0, nativeOptions);
}
diff --git a/Source/cmake.h b/Source/cmake.h
index fac86c1..88847cf 100644
--- a/Source/cmake.h
+++ b/Source/cmake.h
@@ -364,7 +364,8 @@ class cmake
const std::string target,
const std::string config,
const std::vectorstd::string nativeOptions,
-bool
[Cmake-commits] CMake branch, next, updated. v2.8.5-1313-g117120b
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 117120b3208354440fe14b997faa5f708abf5cc8 (commit)
via 317d077f6ed05640f86efbcb5c34d776a4ad9590 (commit)
from 3a86ea655d51b861ce00309fecdcfcb02946ec83 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=117120b3208354440fe14b997faa5f708abf5cc8
commit 117120b3208354440fe14b997faa5f708abf5cc8
Merge: 3a86ea6 317d077
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Jul 27 09:44:20 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 27 09:44:20 2011 -0400
Merge topic 'library-multiarch-issue-12326' into next
317d077 multiarch: Treat lib/arch as implicit link dir (#12326)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=317d077f6ed05640f86efbcb5c34d776a4ad9590
commit 317d077f6ed05640f86efbcb5c34d776a4ad9590
Author: Modestas Vainius mo...@debian.org
AuthorDate: Mon Jul 25 13:24:41 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Jul 27 09:13:58 2011 -0400
multiarch: Treat lib/arch as implicit link dir (#12326)
Add multiarch library directories to the set of implicit link
directories. In particular, this keeps lib/arch out of R(UN)PATH.
diff --git a/Source/cmComputeLinkInformation.cxx
b/Source/cmComputeLinkInformation.cxx
index e3c33a2..c87b64d 100644
--- a/Source/cmComputeLinkInformation.cxx
+++ b/Source/cmComputeLinkInformation.cxx
@@ -1603,6 +1603,18 @@ void cmComputeLinkInformation::LoadImplicitLinkInfo()
cmSystemTools::ExpandListArgument(implicitLinks, implicitDirVec);
}
+ // Append library architecture to all implicit platform directories
+ // and add them to the set
+ if(const char* libraryArch =
+ this-Makefile-GetDefinition(CMAKE_LIBRARY_ARCHITECTURE))
+{
+for (std::vectorstd::string::const_iterator i = implicitDirVec.begin();
+ i != implicitDirVec.end(); ++i)
+ {
+ this-ImplicitLinkDirs.insert(*i + / + libraryArch);
+ }
+}
+
// Get language-specific implicit directories.
std::string implicitDirVar = CMAKE_;
implicitDirVar += this-LinkLanguage;
---
Summary of changes:
Source/cmComputeLinkInformation.cxx | 12
1 files changed, 12 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.5-1316-g819979a
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 819979a11ae840c52e553227417b1ea7212e7667 (commit)
via b7f3f7cdb62fcadba806aca8168c88a9a637eda6 (commit)
via 49a00ec2def5882aa056638c3ae0b3088157de93 (commit)
from 117120b3208354440fe14b997faa5f708abf5cc8 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=819979a11ae840c52e553227417b1ea7212e7667
commit 819979a11ae840c52e553227417b1ea7212e7667
Merge: 117120b b7f3f7c
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Jul 27 18:20:39 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Jul 27 18:20:39 2011 -0400
Merge topic 'add-flag-detection-regex' into next
b7f3f7c Add fail regex to detect supported warning flags correctly.
49a00ec KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b7f3f7cdb62fcadba806aca8168c88a9a637eda6
commit b7f3f7cdb62fcadba806aca8168c88a9a637eda6
Author: David Cole david.c...@kitware.com
AuthorDate: Wed Jul 27 15:01:50 2011 -0400
Commit: David Cole david.c...@kitware.com
CommitDate: Wed Jul 27 15:01:50 2011 -0400
Add fail regex to detect supported warning flags correctly.
On Apple's gcc, the compiler emits a warning such as warning: command
line option -Wno-deprecated is valid for C++/ObjC++ but not for C
when it is passed that flag on its command line.
When testing for that flag with a plain C file, we should report that
the flag is unsupported for C files. The new FAIL_REGEX option added
here produces this behavior.
diff --git a/Modules/CheckCCompilerFlag.cmake b/Modules/CheckCCompilerFlag.cmake
index a03b64d..a390b38 100644
--- a/Modules/CheckCCompilerFlag.cmake
+++ b/Modules/CheckCCompilerFlag.cmake
@@ -27,6 +27,8 @@ MACRO (CHECK_C_COMPILER_FLAG _FLAG _RESULT)
SET(CMAKE_REQUIRED_DEFINITIONS ${_FLAG})
CHECK_C_SOURCE_COMPILES(int main(void) { return 0; } ${_RESULT}
# Some compilers do not fail with a bad flag
+ FAIL_REGEX warning: command line option .* is valid for .* but not for C
+# Apple gcc
FAIL_REGEX unrecognized .*option # GNU
FAIL_REGEX ignoring unknown option # MSVC
FAIL_REGEX warning D9002 # MSVC, any lang
@@ -36,4 +38,3 @@ MACRO (CHECK_C_COMPILER_FLAG _FLAG _RESULT)
)
SET (CMAKE_REQUIRED_DEFINITIONS ${SAFE_CMAKE_REQUIRED_DEFINITIONS})
ENDMACRO (CHECK_C_COMPILER_FLAG)
-
---
Summary of changes:
Modules/CheckCCompilerFlag.cmake |3 ++-
Source/kwsys/kwsysDateStamp.cmake |2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.5-74-gb6fb213
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 b6fb213ed1431321fab0705beb3aae82f451dcc8 (commit) from 49a00ec2def5882aa056638c3ae0b3088157de93 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6fb213ed1431321fab0705beb3aae82f451dcc8 commit b6fb213ed1431321fab0705beb3aae82f451dcc8 Author: KWSys Robot kwro...@kitware.com AuthorDate: Thu Jul 28 00:01:18 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Thu Jul 28 00:12:21 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index 33cd79b..840896e 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 07) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 27) +SET(KWSYS_DATE_STAMP_DAY 28) --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
