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 "-Wl,--kil
Zitat von Maxime Lecourt :
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 L
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 m
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 )
c:/Users/BAAMARNA5617/Programs/CMa
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 pa
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
> Zitat von Maxime Lecourt :
>
> The declarations in my_c_header.h are surrounded by
>>
>> #if defined(__cplusplus)
>>extern "C" {
>> #endif
>> /
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 wrote:
> On 5/31/2011 12:57 PM, Bill Lorensen wrote:
>>
>> Steve,
>>
>> I'm not sure why cma
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 I
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 (aft
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, fo
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 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 recognisab
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 CMakeL
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 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 other Kit
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 wit
On 06/01/2011 09:27 PM, Benjamin Peterson wrote:
> Michael Wild 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 th
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
htt
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 \${CTEST_CONFI
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 behav
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 wrote:
> On 6/1/2011 10:13 A
26 matches
Mail list logo
