The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=12245
==
Reported By:alexander_schmid
Assigned To:
Hi Folks,
I've reconfigured the way our topic stage works to deal better
in cases that topics conflict when merging to next:
- Topics based on next will be rejected when they are pushed.
- Use of the topic stage is now *required*. You will not be able
to merge to 'next' yourself and push
Hello,
I'm having what is probably a newbie problem, but a problem to me.
I have C source files in two different directories, that I use to build a
dll, that is loaded by another C++ project.
I tried to build C objects and link with C++
set_target_properties(ppc PROPERTIES LINK_FLAGS
Zitat von Maxime Lecourt maxime.leco...@gmail.com:
I'm having what is probably a newbie problem, but a problem to me.
I have C source files in two different directories, that I use to build a
dll, that is loaded by another C++ project.
I tried to build C objects and link with C++
The declarations in my_c_header.h are surrounded by
#if defined(__cplusplus)
extern C {
#endif
// functions and stuff declarations
#if defined(__cplusplus)
}
#endif
So i'm not sure about whether it's taken into account or not, and how to
have CMake take it into account when I compile my
Dear Bill,
When i did cmake --trace, I could see at some places BLAS_LIBRARIES are set to
FALSE. Particularly, here in below lines
***
c:/Users/BAAMARNA5617/Programs/CMake
2.8/share/cmake-2.8/Modules/FindBLAS.cmake(322): if(WIN32 )
Hi!
I've been using cmake and cpak on Linux for my project (a library)
without any problems. I'm now trying to get it to work with Visual C++
Express 10. It compiles fine, and puts files (from the project
directory) into meteoio/Release (both a .dll and a .lib). When running
cpack, it only
If that really is your exact code from cmake you are building a
static library only. There must be another argument to the add_library
command that says SHARED. With out that argument cmake will always
generate a static library build.
Also Visual Studio will generate the Release subdirectory
Problem solved.
The problem with linking with the C++ lib comes from C++ lib, and has
nothing to do with CMake
Thanks.
2011/6/1 Hendrik Sattler p...@hendrik-sattler.de
Zitat von Maxime Lecourt maxime.leco...@gmail.com:
The declarations in my_c_header.h are surrounded by
#if
I can't reproduce the problem although I did recently upgrade to cmake 2.8.4.
It is important to have c:/MinGW/bin (or your bin location) in the system path.
On Tue, May 31, 2011 at 2:00 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 5/31/2011 12:57 PM, Bill Lorensen wrote:
Steve,
I'm
On 06/01/2011 12:37 PM, Michael Jackson wrote:
If that really is your exact code from cmake you are building a
static library only. There must be another argument to the add_library
command that says SHARED.
In a subdirectory (after searching for SHARED in all my CMakeLists), I
have OPTION(
If I have several files with a .cc or .cpp filename extension that I
want to compile using Octave's mkoctfile script (a wrapper that turns
them into loadable object code in a form recognisable by the Octave
interpreter), how should I do it?
I thought I could do it with add_custom_command, but as
On Jun 1, 2011, at 11:08 AM, Mathias Bavay wrote:
On 06/01/2011 12:37 PM, Michael Jackson wrote:
If that really is your exact code from cmake you are building a
static library only. There must be another argument to the add_library
command that says SHARED.
In a subdirectory (after
In my project I build a library and a series of tests; so the result is
something like:
build/libblah.so
build/tests/test_series
build/tests/test_archives
etc.
One of the tests I want to run (test_archives) reads from a zip file;
however, for my test to run successfully it needs a zip file place
On 06/01/2011 05:19 PM, Jordi Gutiérrez Hermoso wrote:
If I have several files with a .cc or .cpp filename extension that I
want to compile using Octave's mkoctfile script (a wrapper that turns
them into loadable object code in a form recognisable by the Octave
interpreter), how should I do
On 06/01/2011 05:31 PM, Doug wrote:
In my project I build a library and a series of tests; so the result is
something like:
build/libblah.so
build/tests/test_series
build/tests/test_archives
etc.
One of the tests I want to run (test_archives) reads from a zip file;
however, for my test
Is it improper to use add_definitions to set compile flags instead of
set_source_files_properties and the COMPILE_FLAGS property? The reason I ask is
that I prefer the recursive behavior of add_definitions, but
set_source_files_properties appears to be more modern.
On 1 June 2011 10:41, Michael Wild them...@gmail.com wrote:
On 06/01/2011 05:19 PM, Jordi Gutiérrez Hermoso wrote:
If I have several files with a .cc or .cpp filename extension that I
want to compile using Octave's mkoctfile script (a wrapper that turns
them into loadable object code in a form
What they do is hard code the path to the zip file into a preprocessor define
and then use that preprocessor define in their code. So you have a header
template:
ZipFileLocation.h.in and in there have something like this:
#define ZIP_FILE_LOCATION @ZIP_FILE_LOCATION@
Then in your normal
On 06/01/2011 05:51 PM, Benjamin Peterson wrote:
Is it improper to use add_definitions to set compile flags instead of
set_source_files_properties and the COMPILE_FLAGS property? The reason I ask
is
that I prefer the recursive behavior of add_definitions, but
set_source_files_properties
Michael Wild themiwi@... writes:
Yes, it is considered to be bad practice. If you want the same behavior,
though, use set_directory_properties().
But there's no COMPILE_FLAGS property on directories, is there?
___
Powered by www.kitware.com
Visit
On 6/1/2011 10:13 AM, Bill Lorensen wrote:
I can't reproduce the problem although I did recently upgrade to cmake 2.8.4.
It is important to have c:/MinGW/bin (or your bin location) in the system path.
If c:/MinGW/bin is in your PATH then it will always work. However, it
should also work
On 06/01/2011 09:27 PM, Benjamin Peterson wrote:
Michael Wild themiwi@... writes:
Yes, it is considered to be bad practice. If you want the same behavior,
though, use set_directory_properties().
But there's no COMPILE_FLAGS property on directories, is there?
Ooops, sorry. Just append to
Hi,
if I use PackageMaker, DragNDrop, Bundle, OSXX11 then the problem is that all 4
filenames are equal (e.g. Project.dmg).
The problem now is, that each cpack routine overwrites the package.
Is it possible to avoid this behavior with a custom filename per Generator?
E.g.: Project_OSXX11.dmg,
Hi,
is it possible to also report CPack errors to CDash, for example if NSIS fails
on Linux/Windows?
If so, how could this be done?
Thanks in advance
Best Regards
NoRulez
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Wednesday, June 01, 2011 03:01:12 pm NoRulez wrote:
Hi,
is it possible to also report CPack errors to CDash, for example if NSIS
fails on Linux/Windows?
If so, how could this be done?
You can do this:
ADD_TEST(package ${CMAKE_CPACK_COMMAND} -V
-C
On Wednesday, June 01, 2011 02:58:22 pm NoRulez wrote:
Hi,
if I use PackageMaker, DragNDrop, Bundle, OSXX11 then the problem is that
all 4 filenames are equal (e.g. Project.dmg). The problem now is, that
each cpack routine overwrites the package.
Is it possible to avoid this behavior with
I have different problems if I remove it. When I run cmake cannot find
several dll's required for the compilers to work are missing. So I
think as part of the install process, a mingw user should add it to
their path.
Bill
On Wed, Jun 1, 2011 at 3:44 PM, Bill Hoffman bill.hoff...@kitware.com
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 9d7b53281a3f2c8dac532378760de3fc4495c722 (commit)
via
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 955f96d3e855ea11df5bf73b1211d9c060d00917 (commit)
via
30 matches
Mail list logo
