Hi, developers,
When I look at Platform/UnixPaths.cmake file, I found that
CMAKE_SYSTEM_LIBRARY_PATH is hardcoded.
This means that find_library() does not honor system-wide
library path settings which may be set by system admininstrator
and/or OS policy and fails to find libraries even if you can
Hello,
I try to compare Makefiles generated by your scripts and mine. I don't see
any big differences, except the copy rules.
While trying your scripts, I also reproduced a similar bug.
Generating file_node.cmx
Generating message_node.cmi
Generating file_node.cmi
File "/Users/judi/src/ocaml/cmak
On Thu, 21 Jan 2010 11:27:19 -0600, Mark Moll wrote:
> Wouldn’t it be possible to use “nm” to detect the Fortran name mangling? For
> example:
Sure, provided you have nm.
Jed
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
On Jan 21, 2010, at 10:22 AM, Jed Brown wrote:
> On Thu, 21 Jan 2010 09:17:22 -0600, Mark Moll wrote:
>> You *can* use the Fortran BLAS/LAPACK libraries with C/C++ code.
>
> Yes, this is actually very common, but check_fortran_function_exists
> works by trying to link an actual Fortran program.
On Thu, 21 Jan 2010 16:55:20 +, Mateusz Loskot wrote:
> Yes, though I'd annoyingly keep my side that CXX variants of the macros
> would be useful and make C vs C++ separation more clear to user.
The problem is that the interface for the C++ variant *cannot* look like
check_function_exists, be
Michael Wild wrote:
On 21. Jan, 2010, at 17:17 , Jed Brown wrote:
On Thu, 21 Jan 2010 17:03:27 +0100, Michael Wild
wrote:
But both of them just do a try_compile. I don't see where the
name-mangling comes in there... If the user wants to check for a
template, he has to instantiate the templat
Eric Noulard wrote:
2010/1/21 Mateusz Loskot :
The fact check_function_exists checks C function but not C++ free
function is a bit confusing.
That's true.
AFAIU, CMake is dedicated to build C++ source code,
However that's look false to me :-(
Perhaps I should be more precise, I meant
CM
On 21. Jan, 2010, at 17:17 , Jed Brown wrote:
> On Thu, 21 Jan 2010 17:03:27 +0100, Michael Wild wrote:
>> But both of them just do a try_compile. I don't see where the
>> name-mangling comes in there... If the user wants to check for a
>> template, he has to instantiate the template,
>> e.g. ch
On Thu, 21 Jan 2010 09:17:22 -0600, Mark Moll wrote:
> You *can* use the Fortran BLAS/LAPACK libraries with C/C++ code.
Yes, this is actually very common, but check_fortran_function_exists
works by trying to link an actual Fortran program. When calling from C,
you have to know how Fortran names
On Thu, 21 Jan 2010 17:03:27 +0100, Michael Wild wrote:
> But both of them just do a try_compile. I don't see where the
> name-mangling comes in there... If the user wants to check for a
> template, he has to instantiate the template,
> e.g. check_cxx_function_exists("std::copy std::string::iterat
On 21. Jan, 2010, at 16:57 , Jed Brown wrote:
> On Thu, 21 Jan 2010 15:44:43 +, Mateusz Loskot wrote:
>> Why it can not work, actually?
>
> C++ does name mangling so it's difficult to determine what the symbol
> actually is (you have to know about various classes and templates that
> may be
On Thu, 21 Jan 2010 15:44:43 +, Mateusz Loskot wrote:
> Why it can not work, actually?
C++ does name mangling so it's difficult to determine what the symbol
actually is (you have to know about various classes and templates that
may be in scope), therefore the interface would look a bit differ
Hi everybody
I 've got a problem with a program mixing fortran c and c++ when i want
to use g95.
It works fine with ifort and gfortran but with g95 it send me this error:
- The Fortran compiler identification is G95
-- The C compiler identification is GNU
-- The CXX compiler identification is
Michael Wild wrote:
On 21. Jan, 2010, at 16:44 , Mateusz Loskot wrote:
Michael Wild wrote:
On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote:
Hi, I'm trying to perform the following checks:
check_function_exists(std::pow HAVE_POW) or
check_symbol_exists(std::pow cmath HAVE_POW) but it looks
2010/1/21 Mateusz Loskot :
> The fact check_function_exists checks C function but not C++ free
> function is a bit confusing.
That's true.
> AFAIU, CMake is dedicated to build C++ source code,
However that's look false to me :-(
> so I suppose many users may expect it works
> well for both C a
On 21. Jan, 2010, at 16:44 , Mateusz Loskot wrote:
> Michael Wild wrote:
>> On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote:
>>> Hi,
>>> I'm trying to perform the following checks:
>>> check_function_exists(std::pow HAVE_POW)
>>> or
>>> check_symbol_exists(std::pow cmath HAVE_POW)
>>> but it lo
Michael Wild wrote:
On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote:
Hi,
I'm trying to perform the following checks:
check_function_exists(std::pow HAVE_POW)
or
check_symbol_exists(std::pow cmath HAVE_POW)
but it looks that both macros have troubles with resolving std::
namespace.
The
On Jan 20, 2010, at 10:53 PM, Alan W. Irwin wrote:
> On 2010-01-21 11:03+0900 Ryo IGARASHI wrote:
>
>> Dear developers,
>>
>> Currently, FindLAPACK.cmake and FindBLAS.cmake *requires* Fortran compiler.
>> However, I can easily think of a situation when no Fortran compiler
>> but LAPACK/BLAS
>>
What does it mean when my continuous build seems to process coverage just
fine, but doesn't seem to get any results? I can use my own coverage tool
and get results that are correct so the coverage build is working. I think
I'm just missing a simple thing here. I get:
Performing coverage
Proc
Chauhan, Vikas wrote:
Hi,
I have a very interesting problem. It is described below.
I have two projects Proj1 & Proj2 under a top level root directory.
Now, the build steps are as follows:
1. Build Proj1 into Proj1.exe
2. Execute Proj1.exe and it generates source1.cpp as an output (
On 21. Jan, 2010, at 12:07 , Marcel Loose wrote:
> On Thu, 2010-01-21 at 10:14 +0100, Michael Wild wrote:
>> On 21. Jan, 2010, at 9:56 , Marcel Loose wrote:
>>
>>> On Thu, 2010-01-21 at 06:52 +0100, Michael Wild wrote:
On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote:
> Hi,
>
On Thu, 2010-01-21 at 10:14 +0100, Michael Wild wrote:
> On 21. Jan, 2010, at 9:56 , Marcel Loose wrote:
>
> > On Thu, 2010-01-21 at 06:52 +0100, Michael Wild wrote:
> >> On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm trying to perform the following checks:
> >
On 21. Jan, 2010, at 9:56 , Marcel Loose wrote:
> On Thu, 2010-01-21 at 06:52 +0100, Michael Wild wrote:
>> On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote:
>>
>>> Hi,
>>>
>>> I'm trying to perform the following checks:
>>>
>>> check_function_exists(std::pow HAVE_POW)
>>>
>>> or
>>>
>>> ch
On Thu, 2010-01-21 at 06:52 +0100, Michael Wild wrote:
> On 21. Jan, 2010, at 24:55 , Mateusz Loskot wrote:
>
> > Hi,
> >
> > I'm trying to perform the following checks:
> >
> > check_function_exists(std::pow HAVE_POW)
> >
> > or
> >
> > check_symbol_exists(std::pow cmath HAVE_POW)
> >
> > bu
Hi all,
I noticed a behaviour of CMAKE_CONFIGURATION_TYPES and CMAKE_BUILD_TYPE
that is close to wizardry in my opinion when it comes to 'make install'
It seems that 'make install' prefers to use "install configurations"
that are predefined in CMake (i.e. debug, minsizerel, release, etc.)
over us
25 matches
Mail list logo
