On 2009-07-16 13:23-0700 Alan W. Irwin wrote:
Hi David:
[...] Your idea (for temporarily working around bug 9220)
even takes care of the broken compiler case. (My attempted workaround only
took care of the missing compiler case.) I will implement that workaround
for now for the PLplot build sy
Dear CMake maintainers,
I use Qt on Windows and discovered a BUG in FindQt4.cmake from CMake
2.6.4, when you use the macro QT4_WRAP_CPP for an input file coming from
another drive different from the current build drive. The problem occurs
from the fact that QT4_MAKE_OUTPUT_FILE macro was supp
On Thu, Jul 16, 2009 at 4:23 PM, Alan W. Irwin wrote:
> On 2009-07-16 13:51-0400 Bill Hoffman wrote:
>
> I am not really sure what this issue is...
>>
>>
>> This is certainly not an expected use case:
>>
>> include(CMakeDetermineCompiler)
>> before
>> enable_language( OPTIONAL)
>>
>> If you look
On 2009-07-16 13:51-0400 Bill Hoffman wrote:
I am not really sure what this issue is...
This is certainly not an expected use case:
include(CMakeDetermineCompiler)
before
enable_language( OPTIONAL)
If you look in cmGlobalGenerator.cxx there is a big comment about how all
the$
files work to
2009/7/16 Bill Hoffman :
> Alin M Elena wrote:
>>>
>>> I think the previous posts are missing the question I think what
>>> is wanted is a way to run cmake-gui pick some options, and then generate
>>> a -D command line equivalent to the options that were picked in
>>> cmake-gui. This is not
Alan W. Irwin wrote:
On 2009-07-15 22:54-0600 Clinton Stimpson wrote:
I don't have much to say except that ccmake behaves the same as
cmake-gui in this case.
You can add this at the end to see it.
set(MYSTATUS ${CMAKE_CXX_COMPILER_WORKS} CACHE STRING "")
Thanks for pointing that out. This
Timothy M. Shead wrote:
Michael Wild wrote:
On 16. Jul, 2009, at 16:17, Bill Hoffman wrote:
Michael Wild wrote:
Actually, I'm planning on doing this with the .def files. But then,
maintaining them might also become a nightmare.
You can generate them if you use dumpbin and some scripting
Alin M Elena wrote:
I think the previous posts are missing the question I think what
is wanted is a way to run cmake-gui pick some options, and then generate
a -D command line equivalent to the options that were picked in
cmake-gui. This is not possible, and would be difficult to implement
On Thu, Jul 16, 2009 at 5:01 PM, Mathieu
Malaterre wrote:
> On Thu, Jul 16, 2009 at 4:58 PM, Michael
> Jackson wrote:
>>
>>
>> On Jul 16, 2009, at 10:41 AM, Mathieu Malaterre wrote:
>>
>>> On Thu, Jul 16, 2009 at 4:32 PM, David Cole wrote:
There is not a built-in method of identifying cod
> I think the previous posts are missing the question I think what
> is wanted is a way to run cmake-gui pick some options, and then generate
> a -D command line equivalent to the options that were picked in
> cmake-gui. This is not possible, and would be difficult to implement.
Thanks Bill
[sorry for cross post]
On Thu, Jul 16, 2009 at 5:22 PM, Julien Jomier wrote:
> That's a very good point Jeff, yes it is still case sensitive.
I guess someone should point that out to cmake dev :)
$ grep -i warni * | grep -v Warning:
AddExternalProject.cmake:message(AUTHOR_WARNING "unknow
David E DeMarle wrote:
On Jul 16, 2009, at 10:41 AM, Alin M Elena wrote:
Hi
cmake-gui is very useful for big projects with many variables to set, but
sometimes command line is very necessary, too. Is there a way to generate
the
command line equivalent of the settings from cmake-gui?
I think
Hi ,
It seems that I was misunderstood. I want to know if if possible to see the
equivalent cmake line of the Generate button.
regards,
Alin
--
__
"If the Universities will not study useless subjects, who will?"
You also have the option of running:
"cmake -i" which acts like the old linux kernel configuration tools,
interactively questioning you for each option.
or
"cmake -D setting1 -D setting2..."
David E DeMarle
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371
On Thu, Jul 16, 2009 at 4:58 PM, Michael
Jackson wrote:
>
>
> On Jul 16, 2009, at 10:41 AM, Mathieu Malaterre wrote:
>
>> On Thu, Jul 16, 2009 at 4:32 PM, David Cole wrote:
>>>
>>> There is not a built-in method of identifying code like that, although
>>> that
>>> would be a good feature request. E
ccmake - which is a curses based gui from the cli.
_
Mike Jackson mike.jack...@bluequartz.net
www.bluequartz.net
On Jul 16, 2009, at 10:41 AM, Alin M Elena wrote:
Hi
cmake-gui is very useful for big projects
On Jul 16, 2009, at 10:41 AM, Mathieu Malaterre wrote:
On Thu, Jul 16, 2009 at 4:32 PM, David Cole
wrote:
There is not a built-in method of identifying code like that,
although that
would be a good feature request. Especially if it had a patch
attached to
it... :-)
I can open a feature
Hi
cmake-gui is very useful for big projects with many variables to set, but
sometimes command line is very necessary, too. Is there a way to generate the
command line equivalent of the settings from cmake-gui?
regards,
Alin
--
___
Michael Wild wrote:
On 16. Jul, 2009, at 16:17, Bill Hoffman wrote:
Michael Wild wrote:
Actually, I'm planning on doing this with the .def files. But then,
maintaining them might also become a nightmare.
You can generate them if you use dumpbin and some scripting
But, it is much easie
On Thu, Jul 16, 2009 at 4:32 PM, David Cole wrote:
> There is not a built-in method of identifying code like that, although that
> would be a good feature request. Especially if it had a patch attached to
> it... :-)
I can open a feature request :-)
> You could try this at the top of your CMakeLi
On 16. Jul, 2009, at 16:17, Bill Hoffman wrote:
Michael Wild wrote:
Actually, I'm planning on doing this with the .def files. But then,
maintaining them might also become a nightmare.
You can generate them if you use dumpbin and some scripting
But, it is much easier to just use the
There is not a built-in method of identifying code like that, although that
would be a good feature request. Especially if it had a patch attached to
it... :-)
You could try this at the top of your CMakeLists.txt file:
function(SUBDIRS)
message(FATAL_ERROR "error: using deprecated SUBDIRS")
endfu
Hi there,
I would like to know if anyone was able to get cmake to report
*configuration* error or warning to cdash ? I am looking at:
http://www.vtk.org/Wiki/CMake_Testing_With_CTest
And I can only find regular expression for the build process (not
the configuration stage).
Anyone ?
--
Mat
Hi there,
I would like cmake to report any deprecated functionalities still
being in use on my project (it would ideally return the filename +
line number where it is being used). I was not able to find a way of
doing that. Typically I would like to get rid of call to
install_files() and subdirs
Michael Wild wrote:
Actually, I'm planning on doing this with the .def files. But then,
maintaining them might also become a nightmare.
You can generate them if you use dumpbin and some scripting But, it
is much easier to just use the declspec stuff
-Bill
__
On 16. Jul, 2009, at 15:46, Eric Noulard wrote:
2009/7/16 Michael Wild :
GCC even supports that feature:
http://gcc.gnu.org/wiki/Visibility
in particular you may read "2.2 Export Control" in
http://people.redhat.com/drepper/dsohowto.pdf
I don't say that this is evil. I only say that REQUIR
2009/7/16 Michael Wild :
>> GCC even supports that feature:
>>
>> http://gcc.gnu.org/wiki/Visibility
>>
>> in particular you may read "2.2 Export Control" in
>> http://people.redhat.com/drepper/dsohowto.pdf
>
> I don't say that this is evil. I only say that REQUIRING it is really bad.
OK I missed
On 16. Jul, 2009, at 15:39, Andreas Pakulat wrote:
On 16.07.09 15:26:16, Eric Noulard wrote:
2009/7/16 Michael Wild :
May be there is some equivalent on Windows platform too
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
[just pointing the link, I'm really no windows expert and
On 16. Jul, 2009, at 15:26, Eric Noulard wrote:
2009/7/16 Michael Wild :
May be there is some equivalent on Windows platform too
http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
[just pointing the link, I'm really no windows expert and
don't want to become one :-) ]
Serious
On 16.07.09 15:26:16, Eric Noulard wrote:
> 2009/7/16 Michael Wild :
> >>
> >> May be there is some equivalent on Windows platform too
> >> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
> >> [just pointing the link, I'm really no windows expert and
> >> don't want to become one
2009/7/16 Michael Wild :
>>
>> May be there is some equivalent on Windows platform too
>> http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx
>> [just pointing the link, I'm really no windows expert and
>> don't want to become one :-) ]
>
> Seriously, that platform is just plain broke
On 16. Jul, 2009, at 14:45, Eric Noulard wrote:
2009/7/16 Hendrik Sattler :
Zitat von Michael Wild :
Setting CMAKE_INSTALL_RPATH to "$ORIGIN/../lib/mcrl2" solves the
problem, as the binaries are located in
"${CMAKE_INSTALL_PREFIX}/bin/mcrl2".
On Mac you can set the INSTALL_NAME_DIR prope
2009/7/16 Hendrik Sattler :
> Zitat von Michael Wild :
>>>
>>> Setting CMAKE_INSTALL_RPATH to "$ORIGIN/../lib/mcrl2" solves the
>>> problem, as the binaries are located in
>>> "${CMAKE_INSTALL_PREFIX}/bin/mcrl2".
>>>
>>
>> On Mac you can set the INSTALL_NAME_DIR property (or the
>> CMAKE_INSTALL_N
Hello,
I'm using cmake 2.6.2.
While trying to use the FindLAPACK module on a Linux system which has
ATLAS installed I stumbled upon a problem where the BLAS libraries
would not be found. By digging into FindBLAS.cmake I discovered that
when checking for the ATLAS libraries, the module tries to mak
Zitat von Michael Wild :
Setting CMAKE_INSTALL_RPATH to "$ORIGIN/../lib/mcrl2" solves the
problem, as the binaries are located in "${CMAKE_INSTALL_PREFIX}/bin/mcrl2".
On Mac you can set the INSTALL_NAME_DIR property (or the
CMAKE_INSTALL_NAME_DIR variable) to something starting with
@executab
On 16. Jul, 2009, at 9:26, Frank Stappers wrote:
Hendrik Sattler wrote:
Am Mittwoch 15 Juli 2009 17:20:25 schrieb Frank Stappers:
With the help of CPack we would like to make packages. Currently,
we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
STGZ, GZ). For static builds
Hendrik Sattler wrote:
> Am Mittwoch 15 Juli 2009 17:20:25 schrieb Frank Stappers:
>> With the help of CPack we would like to make packages. Currently,
>> we can make packages for MAC OSX (DMG, TSGZ, GZ) and UNIX (RPM, DEB,
>> STGZ, GZ). For static builds (so no shared libraries) these packages
>>
37 matches
Mail list logo