Hi,
I slept over it, I think here's a better idea.
For every find_package() which is not REQUIRED, some people or packagers may
want to explicitely disable each one of them.
So how about this:
if there is no REQUIRED keyword in the find_package() call, there is always an
option added which
Hi,
after reading some stuff about integration of KDE-stuff into cmake, I
want to know your oppinion about manpages. At least on unix-based
systems it's an essential function of a build-environment to allow
installation of the docs.
My suggestion is, to add a new property like man-source-dir
2011/6/7 Alexander Neundorf neund...@kde.org:
On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
[...]
What do you think about adding the keyword OPTIONAL to add_subdirectory ?
Both have been proven useful, the one for find_package()
2011/6/7 Eric Noulard eric.noul...@gmail.com:
2011/6/7 Alexander Neundorf neund...@kde.org:
On Monday, June 06, 2011 03:26:03 PM Brad King wrote:
On 06/04/2011 06:30 AM, Alexander Neundorf wrote:
[...]
What do you think about adding the keyword OPTIONAL to add_subdirectory ?
Both have
2011/6/7 Werner Mahr wer...@vollstreckernet.de:
Hi,
after reading some stuff about integration of KDE-stuff into cmake, I
want to know your oppinion about manpages. At least on unix-based
systems it's an essential function of a build-environment to allow
installation of the docs.
My
Eric Noulard wrote:
My suggestion is, to add a new property like man-source-dir or
somehow like that, and all pages in that dir are installed to the
right place if they start with the name of the corresponding
executable.
Have a look at the new (in 2.8.4) GnuInstallDirs.cmake module:
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12253
==
Reported By:Fabien Spindler
Assigned To:
On 06/07/2011 03:47 PM, Werner Mahr wrote:
Eric Noulard wrote:
My suggestion is, to add a new property like man-source-dir or
somehow like that, and all pages in that dir are installed to the
right place if they start with the name of the corresponding
executable.
Have a look at the new
On 06/07/2011 10:31 AM, Michael Wild wrote:
install(FILES cmake.1
DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc)
Actually that should be CMAKE_INSTALL_MANDIR. The documentation of
GnuInstallDirs specifies that the variables without _FULL_ are meant
for passing to install
Michael Wild wrote:
Rename from appname.section or appname.lang.section to
appname
install to $mandir/section/appname[.gz] or
$mandir/section/lang/appname[.gz]
install(FILES cmake.1
DESTINATION ${CMAKE_INSTALL_FULL_MANDIR}/man1 COMPONENT doc)
If you want gzipping, either leave it to
On 06/07/2011 07:40 PM, Werner Mahr wrote:
Michael Wild wrote:
foreach(m amule.1 amule.de.1 locale.7)
get_filename_component(b ${m} NAME_WE)
get_filename_component(e ${m} EXT)
if(e MATCHES (([a-zA-Z_-]+)\\.)?([0-9]))
set(l ${CMAKE_MATCH_2})
set(s ${CMAKE_MATCH_3})
else()
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12254
==
Reported By:Mikael Öhman
Assigned To:
Hi all,
I'm having a problem which I can't quite figure out how to solve.
Basically, I have C++ source code in two directories, each for a
different class. Let's say:
src/X
src/Y
Each one makes a different class but ultimately X makes use of Y
(i.e., an instance of Y is a variable within X's
I have a Python script $program that should be installed under bin/,
but it needs a lot of data that should be installed under
share/$program/. I would like for the install Makefile target to
somehow modify $program to let it know the absolute pathname of where
the data share/$program/ is,
Zitat von Raymond Wan r@aist.go.jp:
Hi all,
I'm having a problem which I can't quite figure out how to solve.
Basically, I have C++ source code in two directories, each for a
different class. Let's say:
src/X
src/Y
Each one makes a different class but ultimately X makes use of Y
(i.e.,
On Tuesday, June 07, 2011 04:41:03 AM jeeyoung kim wrote:
I was wondering if there's some way to prevent make clean in cmake from
re-building external dependencies. I'm using ExternalProject to build third
party c++ libraries, and they do not have to be rebuilt even if I do make
clean.
On
Hi Hendrik,
Thank you for the suggestions!
On Tue, Jun 7, 2011 at 17:02, Hendrik Sattler p...@hendrik-sattler.de wrote:
Zitat von Raymond Wan r@aist.go.jp:
I think/hope so far things are ok... I can compile Y and run it with
no problems. The problem is that X needs access to this
Zitat von Raymond Wan r@aist.go.jp:
Hi Hendrik,
Thank you for the suggestions!
On Tue, Jun 7, 2011 at 17:02, Hendrik Sattler
p...@hendrik-sattler.de wrote:
Zitat von Raymond Wan r@aist.go.jp:
I think/hope so far things are ok... I can compile Y and run it with
no problems. The
Hi Hendrik,
On Tue, Jun 7, 2011 at 17:17, Hendrik Sattler p...@hendrik-sattler.de wrote:
Zitat von Raymond Wan r@aist.go.jp:
Hm, I never thought of the first option! So if I am understanding
your suggestion correctly, this basically means that in X's class
definition, it has an
Unfortunately you can get only list of source files (using SOURCES target's
property). The location of object files depends on Generator (e.g. for
VisualStudio they will be put into configuration-specific location).
On Tue, Jun 7, 2011 at 12:32 AM, dfurt...@cox.net wrote:
Does CMake provide a
I was wondering if there's some way to prevent make clean in cmake from
re-building external dependencies. I'm using ExternalProject to build
third
party c++ libraries, and they do not have to be rebuilt even if I do make
clean.
On the other hand, I might want to create a new rule, say,
Hi all,
As far as I can tell, all Qt programs built with CMake must include
QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
include QT_USE_FILE itself? Is there maybe a use case where
QT_USE_FILE is *not* wanted?
Best regards,
Bjørn Forsman
On 06/07/2011 02:20 PM, Bjørn Forsman wrote:
Hi all,
As far as I can tell, all Qt programs built with CMake must include
QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
include QT_USE_FILE itself? Is there maybe a use case where
QT_USE_FILE is *not* wanted?
Best
If you don't care for the macros and want to set up the
include-directories and defines yourself, no. Also, it is common to
find_package(Qt4) in the top-level CMakeLists.txt file, but then include
QT_USE_FILE only in specific subdirectories, where Qt is actually used.
I have started doing
Thanks for a quick reply!
On 7 June 2011 14:52, Michael Wild them...@gmail.com wrote:
On 06/07/2011 02:20 PM, Bjørn Forsman wrote:
As far as I can tell, all Qt programs built with CMake must include
QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
include QT_USE_FILE
On 06/07/2011 03:21 PM, John Drescher wrote:
If you don't care for the macros and want to set up the
include-directories and defines yourself, no. Also, it is common to
find_package(Qt4) in the top-level CMakeLists.txt file, but then include
QT_USE_FILE only in specific subdirectories, where
On 7 June 2011 15:21, John Drescher dresche...@gmail.com wrote:
If you don't care for the macros and want to set up the
include-directories and defines yourself, no. Also, it is common to
find_package(Qt4) in the top-level CMakeLists.txt file, but then include
QT_USE_FILE only in specific
On 06/07/2011 03:38 PM, Bjørn Forsman wrote:
Thanks for a quick reply!
On 7 June 2011 14:52, Michael Wild them...@gmail.com wrote:
On 06/07/2011 02:20 PM, Bjørn Forsman wrote:
As far as I can tell, all Qt programs built with CMake must include
QT_USE_FILE after find_package(). So why
On Tue, Jun 7, 2011 at 9:46 AM, Michael Wild them...@gmail.com wrote:
On 06/07/2011 03:21 PM, John Drescher wrote:
If you don't care for the macros and want to set up the
include-directories and defines yourself, no. Also, it is common to
find_package(Qt4) in the top-level CMakeLists.txt file,
On 06/07/2011 04:11 PM, Marcus D. Hanwell wrote:
On Tue, Jun 7, 2011 at 9:46 AM, Michael Wild them...@gmail.com wrote:
On 06/07/2011 03:21 PM, John Drescher wrote:
If you don't care for the macros and want to set up the
include-directories and defines yourself, no. Also, it is common to
Hi all,
As far as I can tell, all Qt programs built with CMake must include
QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
include QT_USE_FILE itself? Is there maybe a use case where
QT_USE_FILE is *not* wanted?
Besides the points already given here is another
2011/6/7 Michael Wild them...@gmail.com:
On 06/07/2011 03:38 PM, Bjørn Forsman wrote:
Why not put find_package(Qt4) in the sub directories where it is actually
used?
And if it is used in multiple subdirectories?
What's bad about that? (Sorry, I really don't know).
FindXXX.cmake modules
On 7 June 2011 16:32, Rolf Eike Beer e...@sf-mail.de wrote:
Hi all,
As far as I can tell, all Qt programs built with CMake must include
QT_USE_FILE after find_package(). So why doesn't FindQt4.cmake simply
include QT_USE_FILE itself? Is there maybe a use case where
QT_USE_FILE is *not*
On 06/07/2011 06:23 PM, Bjørn Forsman wrote:
2011/6/7 Michael Wild them...@gmail.com:
On 06/07/2011 03:38 PM, Bjørn Forsman wrote:
Why not put find_package(Qt4) in the sub directories where it is actually
used?
And if it is used in multiple subdirectories?
What's bad about that? (Sorry,
2011/6/7 Michael Wild them...@gmail.com:
On 06/07/2011 06:23 PM, Bjørn Forsman wrote:
2011/6/7 Michael Wild them...@gmail.com:
On 06/07/2011 03:38 PM, Bjørn Forsman wrote:
Why not put find_package(Qt4) in the sub directories where it is actually
used?
And if it is used in multiple
Hi,
I have a number of projects which contain mostly sub-directories with
standard C++. I currently build all this stuff on Linux and Windows
and everything is great. However I have a couple of directories in
these projects which contain managed C++/CLI code so that I can expose
the unmanaged C++
I've reopened Issue 0011279. CMakeDetermineVSServicePack.cmake has been broken
again, this time by VS2010 switching to MSBuild. This has caused the version
string to change. I've created a patch and uploaded it to the Issue:
2011/6/7 Jordi Gutiérrez Hermoso jord...@octave.org:
I have a Python script $program that should be installed under bin/,
but it needs a lot of data that should be installed under
share/$program/. I would like for the install Makefile target to
somehow modify $program to let it know the
Hi
I've two topics related to the support for custom lang in cmake. I
hope you can help me.
1) Does anyone knows plan about merge the following feature related to
the CUDA: http://public.kitware.com/Bug/view.php?id=11887
I'm in the process of integrating the CUDA Toolkit into our build
Hey CMake Mac fans,
I am at Apple's WWDC 2011 conference this week in San Francisco -- if you are
too, and you'd like to meet up, let me know... Reply just to me so we don't get
too much list traffic.
Cheers,
David C.
___
Powered by www.kitware.com
On 6/7/2011 2:50 PM, t m wrote:
Hi
I've two topics related to the support for custom lang in cmake. I
hope you can help me.
1) Does anyone knows plan about merge the following feature related to
the CUDA: http://public.kitware.com/Bug/view.php?id=11887
I'm in the process of integrating the
2011/6/7 Michael Wild them...@gmail.com:
If the FindXXX.cmake file called add_definitions(),
include_directories() et al., that could be potentially harmful. Some
sources might required that some define is not set, or a wrong header
file might be #include'ed (thing of all the different X.h
Hi Folks,
I observed there are different ways of naming binary packages:
myproject-Linux-i386.{ext}
myproject-Linux-amd64.{ext}
myproject-Linux-x86_32.{ext}
myproject-Linux-x86_64.{ext}
myproject-Windows-win32_x86.{ext}
myproject-Windows-win64_x86.{ext}
I think the big problem is that this will only work correctly in makefile
based systems. So, VS and Xcode will not work with this version of the Cuda
stuff.
I understand that you would like to avoid merge changes that
potentially are not adopted
to all platforms/IDEs supported by CMake itself.
I have been hammergin on a vxworks cross-compile toolchain file. It seems that
not all properties that are set in the cross-compilation file propogate to the
CMakeLists.txt file that is using it. An example is the CMAKE_AR property.
Setting it in the cross-compilation file had no effect and
There were some system headers giving warnings compiling on linux,
since I like to have warnings as errors, and not edit system headers,
I used:
include_directories(SYSTEM dir1 dir2 ...)
... for system directories only.
However this does not result in -isystem being used in C because
GNU.cmake
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via f87ed31ce514b1c1c299c8b5b714c283875a5a80 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 1dcc4ac7ae38a0ce87e1be1203c702c8d7b91cc5 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 33b3d10d6e5aaa756fd1e0701caaa4f305e9245a (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 43d3048582e34a84cc061fddeb3e7967a2c7a576 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 40792a1a15f1ee3c0582486aac9182f8eaa1b316 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 06296ca3fd1d7d328756c414517b7f37089272ee (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via cac2eadf44546f9f5e281df77685f9695772ab61 (commit)
via
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, master has been updated
via 0f939ee16478ad638bb380a75b4867b072a09306 (commit)
from
54 matches
Mail list logo
