On Mon, Jan 11, 2010 at 3:39 AM, Keyan wrote:
>> It looks like a couple of the macros don't have the OCAML_ name prefix
>> added to them. For example, COPY_FILE & GET_DEPENDENCIES. You should
>> add the prefix to them as well to prevent name collision when other
>> people use your code.
>
>thank
On Jan 13, 2010, at 4:58 PM, Andreas Pakulat wrote:
On 13.01.10 13:34:34, clin...@elemtech.com wrote:
I've also seen people put a qt.conf file in the Qt installation, to
override the compiled-in paths.
That's probably how its done by the Windows installer.
Thats one way to do it, but appare
> -Original Message-
> From: Bill Hoffman [mailto:bill.hoff...@kitware.com]
> Sent: 12 January 2010 22:05
> To: Chauhan, Vikas
> Cc: Eric Noulard; cmake@cmake.org
> Subject: Re: [CMake] using cmake on windows - query on existing
targets
>
>
> >
> > I noticed that it generates the follow
On 13.01.10 13:34:34, clin...@elemtech.com wrote:
> I've also seen people put a qt.conf file in the Qt installation, to override
> the compiled-in paths.
> That's probably how its done by the Windows installer.
Thats one way to do it, but apparently not the safest. Qt's SDK binary
package has a s
I've also seen people put a qt.conf file in the Qt installation, to override
the compiled-in paths.
That's probably how its done by the Windows installer.
Clint
- Michael Jackson wrote:
> Um, yea, you don't want to do that, change the location of the Qt
> libraries after they are built in
Um, yea, you don't want to do that, change the location of the Qt
libraries after they are built in one location. On Windows, the only
way you can do that (to my knowledge) is to use the MinGW precompiled
binaries from Nokia. When the installer runs all the paths are updated
for the install
So:
set (QT_QMAKE_EXECUTABLE "${mySrc}/ExternalLibs/Qt/qt_current/bin/qmake")
This initially worked. But only initially. Then I did something dastardly: I
got rid of the original place I compiled the libraries -- which qmake still
somehow knows despite being compiled with -no-rpath.
Now I get
The definitive, unambiguous way to do this is to:
set(QT_QMAKE_EXECUTABLE "/full/path/to/qmake")
before:
find_package(Qt4)
Changing the value of QT_QMAKE_EXECUTABLE and then re-executing
find_package(Qt4) is supposed to change all associated Qt variables to match
the corresponding qmake.
On Wed
On 2010-01-13 14:03-0500 Michael Jackson wrote:
SEt the QT_QMAKE_EXECUTABLE variable.
Or put the appropriate version of qmake on your PATH.
Alan
__
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrow
On Wed, Jan 13, 2010 at 12:07:47PM -0600, James Willis wrote:
> Like say you did:
> set(QT_QMAKE_LOCATION /home/myself/qt4.6.0/bin)
> so that I later upgrade and do:
> set(QT_QMAKE_LOCATION /home/myself/qt4.6.1/bin) later without having to muck
> with my path, but still have findQt find Qt there?
I think if you set these two variables you will get the same desired result.
set(DESIRED_QT_VERSION 4)
set(QT_QMAKE_EXECUTABLE /home/qt/4.6.0/bin/qmake)
On Wed, Jan 13, 2010 at 1:07 PM, James Willis wrote:
> Is there any good way of telling findqt (I don't really care about findqt3)
> where to
SEt the QT_QMAKE_EXECUTABLE variable.
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Dayton, Ohio
On Jan 13, 2010, at 1:07 PM
On Wed, Jan 13, 2010 at 1:07 PM, James Willis wrote:
> Is there any good way of telling findqt (I don't really care about findqt3)
> where to find Qt?
>
> Like say you did:
> set(QT_QMAKE_LOCATION /home/myself/qt4.6.0/bin)
> so that I later upgrade and do:
> set(QT_QMAKE_LOCATION /home/myself/qt4
Is there any good way of telling findqt (I don't really care about findqt3)
where to find Qt?
Like say you did:
set(QT_QMAKE_LOCATION /home/myself/qt4.6.0/bin)
so that I later upgrade and do:
set(QT_QMAKE_LOCATION /home/myself/qt4.6.1/bin) later without having to muck
with my path, but still hav
K. Noel Belcourt wrote:
> Brad King wrote:
>> Following this message is a patch series to support PathScale. Please
>> try it locally and send feedback to me. If it works I'll include it to
>> CMake upstream.
> Yes, tested locally. Pathscale builds seems to work fine
Great. I've integrated it
On 1/13/10 7:22 AM, Jed Brown wrote:
On Wed, 13 Jan 2010 07:04:46 -0600, Ryan Pavlik wrote:
You could use the CleanLibraryList module I posted a few emails ago:
just make a list that contains all the libraries you are going to link
your target against, and then just run clean_library_list o
2010/1/13 ctrlaltca :
> The SCRIPT and CODE signature:
>
> install([[SCRIPT ] [CODE ]] [...])
>
> The SCRIPT form will invoke the given CMake script files during
> installation. If the script file name is a relative path it will be
> interpreted with respect to the current source directory. The CO
The SCRIPT and CODE signature:
install([[SCRIPT ] [CODE ]] [...])
The SCRIPT form will invoke the given CMake script files during
installation. If the script file name is a relative path it will be
interpreted with respect to the current source directory. The CODE form
will invoke the given CMa
Hmmm, thought of something like that myself, but am not sure whether
dependencies will be handled correctly. Of course, I'll have to label the
products as GENERATED and add them to ADDITIONAL_MAKE_CLEAN_FILES. Will give
it a try...
Michael
On 13. Jan, 2010, at 16:17 , David Cole wrote:
> T
2010/1/13 Dr. Stefan Sablatnög :
> Hi everybody,
>
>
>
> Does anyone know whether there is a way to build a target only
>
> if “make install” is called? I tried “add_dependencies(install ),
> but
>
> it complains, that the target install does not exist.
>
> Is the install target only available in t
The best way to deal with this is probably to have a single "sentinel" or
"stamp" file that gets generated *every* time the command runs. And then
list that file as it's only output that CMake knows about... (But still with
the full list of inputs.)
Does that work?
On Wed, Jan 13, 2010 at 8:26 A
On 13. Jan, 2010, at 15:15 , Brad King wrote:
> Hi Noel,
>
> Michael's explanation in his response was excellent (thanks Michael!).
Thanks ;-)
BTW, is your git mirror publicly available somewhere?
Michael
___
Powered by www.kitware.com
Visit other
---
Modules/CMakeCCompilerId.c.in |3 +++
Modules/CMakeCXXCompilerId.cpp.in |3 +++
Modules/CMakeFortranCompilerId.F.in |2 ++
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Modules/CMakeCCompilerId.c.in b/Modules/CMakeCCompilerId.c.in
index 6cd6437..5d004c7 100
Hi Noel,
Michael's explanation in his response was excellent (thanks Michael!).
The generalization that Michael described has been swept through many
of the platform files since 2.8.0 was released. This refactoring was
needed to get GNU-specific flags out of Linux.cmake before support for
the Pa
We add compiler information files
Compiler/PathScale-.cmake
to specify PathScale compiler information for C, C++, and Fortran
languages. We use a macro in Compiler/PathScale.cmake to consolidate
the information common to all languages.
---
Modules/Compiler/PathScale-C.cmake |4 +++
Hi everybody,
Does anyone know whether there is a way to build a target only
if make install is called? I tried add_dependencies(install ),
but
it complains, that the target install does not exist.
Is the install target only available in the generated makefiles?
Thanks and best reg
Did you select the VS 2008 64bit generator in CMake but not install the
64bit compiler? It is not installed by default, you have to do a custom
install and select it manually.
On Wed, Jan 13, 2010 at 8:40 AM, Leandro Gazoni wrote:
> Dears,
>
> I'm have a problem to generate a project to compile
Dears,
I'm have a problem to generate a project to compile VTK with visual studio
2008. The CMAKE displays the following error:
Check for working C compiler: cl
Check for working C compiler: cl -- broken
CMake Error at C:/Program Files (x86)/CMake
2.6/share/cmake-2.6/Modules/CMakeTestCCompiler.
Hi all
I just ran into an interesting problem. Say I have a custom command that
produces several files, but only updates them as needed. E.g.
add_custom_command(OUTPUT file1.c file2.c file3.c
COMMAND generator file1.inp file2.inp file3.inp
DEPENDS generator file1.inp file2.inp file3.inp
VE
On Wed, 13 Jan 2010 07:04:46 -0600, Ryan Pavlik wrote:
> You could use the CleanLibraryList module I posted a few emails ago:
> just make a list that contains all the libraries you are going to link
> your target against, and then just run clean_library_list on it before
> doing so.
The troubl
On Wed, 13 Jan 2010 13:51:57 +0100, Nico Schlömer
wrote:
> > Overlinking is actually only an issue for dynamic libraries. So as
> > long as you're absolutely sure that you only have static libraries,
> > you're fine.
>
> Oh, I was thinking it is *unclean* to have a link line like
Overlinking is
On 1/13/10 6:51 AM, Nico Schlömer wrote:
Overlinking is actually only an issue for dynamic libraries. So as long as
you're absolutely sure that you only have static libraries, you're fine.
Oh, I was thinking it is *unclean* to have a link line like
-llibrarya /usr/local/local/liblapack.a
On 13. Jan, 2010, at 13:51 , Nico Schlömer wrote:
>> Overlinking is actually only an issue for dynamic libraries. So as long as
>> you're absolutely sure that you only have static libraries, you're fine.
>
> Oh, I was thinking it is *unclean* to have a link line like
>
> -llibrarya /usr/local/
> Overlinking is actually only an issue for dynamic libraries. So as long as
> you're absolutely sure that you only have static libraries, you're fine.
Oh, I was thinking it is *unclean* to have a link line like
-llibrarya /usr/local/local/liblapack.a --llibraryb
/usr/local/local/liblapack.a
On 13. Jan, 2010, at 11:51 , Nico Schlömer wrote:
>> Coming to think of it: Why don't you simply list ${A_LIBRARY},
>> /usr/lib/liblapack.a and /usr/lib/blas.a (shouldn't that be libblas.a?) in
>> A_LIBRARIES and the use that in TARGET_LINK_LIBRARIES? Simpler for you and
>> less work for CMake
> Coming to think of it: Why don't you simply list ${A_LIBRARY},
> /usr/lib/liblapack.a and /usr/lib/blas.a (shouldn't that be libblas.a?) in
> A_LIBRARIES and the use that in TARGET_LINK_LIBRARIES? Simpler for you and
> less work for CMake...
When using ${A_LIBRARY}, ${B_LIBRARY}, ${G_LIBRARY}
On 12. Jan, 2010, at 18:32 , K. Noel Belcourt wrote:
> Hi,
>
> I've started running nightly cmake tests and submitting them to your
> dashboard. I was hoping the nightly tests would pick up this problem I'm
> having. When compiling Fortran90 code with pathscale-3.2 (pathf90), I get
> this e
On 13. Jan, 2010, at 1:55 , Nico Schlömer wrote:
> Pheeew..
> So I've now been trying to include one *single* library from an
> external project (liba.a) into my own project, writing FindA.cmake.
> Somehow I still fail to apply the dependencies correctly. What I do is
>
> [...]
> ADD_LIBRARY(A S
38 matches
Mail list logo
