Philip Schwartz wrote:
> Currently when setting CMP0015 to old, the warnings are still displayed.
> As the policy is only a warning policy at this time there is no breakage
> of the configure step other then a lot of unneeded warnings.
Use cmake_policy(GET) to check the policy value right before t
Currently when setting CMP0015 to old, the warnings are still displayed. As
the policy is only a warning policy at this time there is no breakage of the
configure step other then a lot of unneeded warnings.
On Thu, Feb 25, 2010 at 1:23 PM, David Cole wrote:
> The policy being set to old is suppo
The policy being set to old is supposed to give the same behavior as prior
versions of CMake, but also suppress the warning.
What behavior are you seeing that makes you say setting it to old "does
nothing"?
On Thu, Feb 25, 2010 at 10:39 AM, Philip Schwartz wrote:
> I think I have found a bug wi
I think I have found a bug with 3.8.1. I have a few projects that use
relative link paths and they throw a warning for CMP0015.
I have pushed to the policy stack CMP0015 OLD to avoid the warnings till I
fix the projects and currently the policy being set to old does nothing.
On Fri, Feb 19, 2010
On Mon, 22 Feb 2010 14:28:05 -0500
Brad King wrote:
On 2/22/2010 1:12 PM, Alan W. Irwin wrote:
I don't have access to Cygwin myself, but as a
convenience for more Cygwin
testing by you and Arjen, I put together a simple test
project that detects
Fortran identically to how it is done in PLplo
On Mon, 22 Feb 2010 10:12:12 -0800 (PST)
"Alan W. Irwin" wrote:
On 2010-02-22 08:35-0500 Brad King wrote:
I cannot reproduce this. I have a simple project:
# CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(Foo Fortran)
I don't have access to Cygwin myself, but as a
convenie
On 2/22/2010 1:12 PM, Alan W. Irwin wrote:
I don't have access to Cygwin myself, but as a convenience for more Cygwin
testing by you and Arjen, I put together a simple test project that detects
Fortran identically to how it is done in PLplot
Thanks. I still get this:
-- The Fortran compiler
On 2010-02-22 08:35-0500 Brad King wrote:
I cannot reproduce this. I have a simple project:
# CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
project(Foo Fortran)
I don't have access to Cygwin myself, but as a convenience for more Cygwin
testing by you and Arjen, I put together a simpl
On 2010-02-22 08:35-0500 Brad King wrote:
Are you using a modified CMakeDetermineFortranCompiler.cmake
in your own CMAKE_MODULE_PATH?
Hi Brad:
I am probably the best person to answer that question. Here is how
I currently implement CMAKE_MODULE_PATH in our svn trunk version of
PLplot.
if(C
On Fri, Feb 19, 2010 at 6:46 AM, Brad King wrote:
> On 2/18/2010 4:35 PM, Ben Medina wrote:
>
>> However, with VS2010, CMake is re-run in the middle of the build.
>>
>
> Did this work in CMake 2.8.0?
>
> I tried some test cases that seem similar to yours but
> I was unable to reproduce this probl
Hi Brad,
I will need to check that - PLplot does/did have a file
CMakeFortranInformation.cmake, maybe that is the culprit.
I will try your minimal project myself, hopefully that will
give the same result, otherwise we will have a mystery at
our hands.
Regards,
Arjen
On 2010-02-22 14:35, Bra
Arjen Markus wrote:
On Thu, 18 Feb 2010 16:21:33 -0800 (PST)
"Alan W. Irwin" wrote:
I have a lot more CMake-2.8.1-RC3 testing to do myself ...
I have come across a nasty little error:
Under Cygwin it turns out that CMake 2.8.1rc3 is not
recognising gfortran, but instead g77.
I cannot rep
I have just solved the java issue I had discovered. The cause was a
recently introduced regression in our own build system and nothing to do
with cmake-2.8.x.
From the PLplot build-system perspective, that leaves just the D static
library issue on Linux which I am still working on, and the For
On Thu, 18 Feb 2010 16:21:33 -0800 (PST)
"Alan W. Irwin" wrote:
I have a lot more CMake-2.8.1-RC3 testing to do myself ...
I have come across a nasty little error:
Under Cygwin it turns out that CMake 2.8.1rc3 is not
recognising gfortran, but instead g77.
The output from the test is ambigu
On Fri, Feb 19, 2010 at 8:46 AM, Brad King wrote:
> On 2/18/2010 4:35 PM, Ben Medina wrote:
>>
>> I just took it for a spin on the Windows side of my projects. It
>> worked flawlessly with VS2005 and VS2008.
>
> Great, thanks for trying it.
>
>> However, with VS2010, CMake is re-run in the middle
On 2/18/2010 4:35 PM, Ben Medina wrote:
I just took it for a spin on the Windows side of my projects. It
worked flawlessly with VS2005 and VS2008.
Great, thanks for trying it.
However, with VS2010, CMake is re-run in the middle of the build.
Did this work in CMake 2.8.0?
I tried some test
On 2/18/2010 8:38 PM, Samuel E. Henley wrote:
I have a new warning "warning: -fPIC ignored for target (all code is
position independent)" Under Windows - Mingw
CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to
be cleared of -fPIC, -fIPC is not used with gcc in Windows.
This
I have a new warning "warning: -fPIC ignored for target (all code is
position independent)" Under Windows - Mingw
CMAKE_SHARED_LIBRARY_C_FLAGS and CMAKE_SHARED_LIBRARY_CXX_FLAGS has to
be cleared of -fPIC, -fIPC is not used with gcc in Windows.
Samuel E. Henley OSRail.net
_
On 2010-02-18 08:52-0800 Alan W. Irwin wrote:
[The information about CMAKE_MODULE_PATH being a list]
is going to help a lot in the
language support transition between 2.6.x and 2.8.x.
To Arjen, Brad, and Bill:
Setting up CMAKE_MODULE_PATH as a list whose contents depended on CMake
version mea
On Wed, Feb 17, 2010 at 7:39 AM, Bill Hoffman wrote:
> CMake 2.8.1 RC 3 is ready to try:
>
> http://www.cmake.org/files/v2.8/?C=M;O=D
>
> Please try your projects with it. If you find any issues, let me know. I
> think we are getting very close to the actual release. Pretty much
> regressions o
Alan W. Irwin wrote:
> On 2010-02-18 08:14-0500 Brad King wrote:
>
>> Alan W. Irwin wrote:
>>> Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths
>>> that are
>>> searched one after another? That would solve the common modules
>>> issue for us.
>>
>> It is already a list:
>>
>>
On 2010-02-18 08:14-0500 Brad King wrote:
Alan W. Irwin wrote:
Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths that are
searched one after another? That would solve the common modules issue for us.
It is already a list:
set(CMAKE_MODULE_PATH /some/path /some/other/path
On 2010-02-18 08:20-0500 Bill Hoffman wrote:
Alan W. Irwin wrote:
I also just discovered that our special CMake D language support
infrastructure fails for the static library case for CMake 2.8.1 RC 3. It
should take me quite a while to see what is wrong in that case, since
language support
Alan W. Irwin wrote:
I also just discovered that our special CMake D language support
infrastructure fails for the static library case for CMake 2.8.1 RC 3. It
should take me quite a while to see what is wrong in that case, since
language support is so "magic" with its own set of hard-to-under
Alan W. Irwin wrote:
> Could CMAKE_MODULE_PATH be treated as a colon-separate list of paths that are
> searched one after another? That would solve the common modules issue for us.
It is already a list:
set(CMAKE_MODULE_PATH /some/path /some/other/path)
list(APPEND CMAKE_MODULE_PATH /some/th
Craig Bradney wrote:
Would these enhancements include finding qmake-mac (as it is named on
OSX installed by MacPorts?) Up until 2.8.0 I have found I need to modify
this file to make it find the qmake binary. Simply adding qmake-mac to
the list of executable names is sufficient.
Yes, that chang
On 2/17/10 4:39 PM, Bill Hoffman wrote:
> CMake 2.8.1 RC 3 is ready to try:
>
> http://www.cmake.org/files/v2.8/?C=M;O=D
>
> Please try your projects with it. If you find any issues, let me
> know. I think we are getting very close to the actual release. Pretty
> much regressions only at this po
On 2010-02-17 10:39-0500 Bill Hoffman wrote:
CMake 2.8.1 RC 3 is ready to try:
http://www.cmake.org/files/v2.8/?C=M;O=D
Please try your projects with it. If you find any issues, let me know. I
think we are getting very close to the actual release. Pretty much
regressions only at this poin
On 2010-02-17 10:39-0500 Bill Hoffman wrote:
CMake 2.8.1 RC 3 is ready to try:
http://www.cmake.org/files/v2.8/?C=M;O=D
Bill, could you please include gpg signature files with each form of your
downloadable release files? If the user imports your public key from your
website or a keyserver u
CMake 2.8.1 RC 3 is ready to try:
http://www.cmake.org/files/v2.8/?C=M;O=D
Please try your projects with it. If you find any issues, let me know.
I think we are getting very close to the actual release. Pretty much
regressions only at this point, so PLEASE test your software with this
rele
30 matches
Mail list logo
