[cmake-developers] [CMake 0012004]: Feature Request: New .cmake file for searching SDL_gfx
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12004 == Reported By:Arttu Valo Assigned To: == Project:CMake Issue ID: 12004 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-03-23 04:48 EDT Last Modified: 2011-03-23 04:48 EDT == Summary:Feature Request: New .cmake file for searching SDL_gfx Description: I noticed, that CMake does not have FindXXX.cmake file for SDL_gfx. Steps to Reproduce: Add find_package(SDL_gfx). This should fail. Additional Information: I have written FindSDL_gfx.cmake, and included it in the bug report. == Issue History Date ModifiedUsername FieldChange == 2011-03-23 04:48 Arttu Valo New Issue 2011-03-23 04:48 Arttu Valo File Added: FindSDL_gfx.cmake == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [Ninja] Start to work on a generator
Hello everyone, This weekend I started to work on a new generator for Ninja. I did not know the internal architecture of CMake so I spent most of my time understanding how it works. I have the very little beginning of something in a local topic branch. It is not able to bootstrap a simple helloworld project yet. I have attached a git log and a git log -p of what I have done so far. Not so much but I will work on it more next weekend. Also, I have few questions about CMake internal architecture. I don't really understand how global and local generator work together? Where should I put my code? in the global or in the local one? I have taken most of the inspiration from the UnixMakefile generator but the Ninja generator has on major difference: Ninja is not design to work in a recursive form. I did some experiment and all the automatic step counting of Ninja does not make sense in a recursive approach. So, I think I should put all my code only in the global generator and generate only one build.ninja file per project. Any help is welcome. Regards, -- Nicolas Desprès git-log-ninja-generator.txt.bz2 Description: BZip2 compressed data git-log-p-ninja-generator.txt.bz2 Description: BZip2 compressed data ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012006]: CPackDeb: packages for different components have the same package name
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12006 == Reported By:Martin Konrad Assigned To: == Project:CMake Issue ID: 12006 Category: CPack Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2011-03-23 17:56 EDT Last Modified: 2011-03-23 17:56 EDT == Summary:CPackDeb: packages for different components have the same package name Description: The current development version of CPackDeb seems to handle Debian package names wrong: If we package more than one components (each into an own package) they all have the same name. This leads to a warning by dpkg when installing the packages. This probably breaks package installation. Solution: Each deb file should get it's own package name e.g. foobar-lib and foobar-headers. Steps to Reproduce: $ make test $ cd Tests/CPackComponentsForAll/buildDEB-OnePackPerGroup/ $ sudo dpkg -i MyLib-1.0.2-Linux-*.deb Selecting previously deselected package mylib. (Reading database ... 301254 files and directories currently installed.) Unpacking mylib (from MyLib-1.0.2-Linux-Development.deb) ... Preparing to replace mylib 1.0.2 (using MyLib-1.0.2-Linux-Runtime.deb) ... Unpacking replacement mylib ... More than one copy of package mylib has been unpacked in this run ! Only configuring it once. Setting up mylib (1.0.2) ... == Issue History Date ModifiedUsername FieldChange == 2011-03-23 17:56 Martin Konrad New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Ninja] Start to work on a generator
On Wed, Mar 23, 2011 at 6:58 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 3/23/2011 9:47 AM, Nicolas Desprès wrote: Hello everyone, This weekend I started to work on a new generator for Ninja. I did not know the internal architecture of CMake so I spent most of my time understanding how it works. I have the very little beginning of something in a local topic branch. It is not able to bootstrap a simple helloworld project yet. I have attached a git log and a git log -p of what I have done so far. Not so much but I will work on it more next weekend. Also, I have few questions about CMake internal architecture. I don't really understand how global and local generator work together? Where should I put my code? in the global or in the local one? I have taken most of the inspiration from the UnixMakefile generator but the Ninja generator has on major difference: Ninja is not design to work in a recursive form. I did some experiment and all the automatic step counting of Ninja does not make sense in a recursive approach. So, I think I should put all my code only in the global generator and generate only one build.ninja file per project. Oups! Sorry for sending the email twice. I canceled the first which was too big but it get published anyway. You should not put all the code in the global generator. I would think it would be better to model it after the VS2010 generator, which is more target based. You still need the local/global generators, but the local generator just cycles over the targets that are in that directory. So, look at cmGlobalVisualStudio10Generator.cxx cmLocalVisualStudio10Generator.cxx cmVisualStudio10TargetGenerator.cxx. Ok. Thanks for the advice. I'll have a look at it this weekend -- Nicolas Desprès ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] ExternalProject + Patch command
Thanks guys.
I ended up with a different (hack) way:
To recap, my issue was that my patch would be applied twice when
building with multi-configuration generators.
Since I am always building the external project with a release
configuration, the following worked fine to disable the
multi-configuration code for the external project.
SET(_backup ${CMAKE_CONFIGURATION_TYPES})
SET(CMAKE_CONFIGURATION_TYPES CACHE STRING FORCE)
ExternalProject_Add(foo
….
)
ExternalProject_Get_Property()
SET(CMAKE_CONFIGURATION_TYPES ${_backup} CACHE STRING FORCE)
/Johan
On Wed, Mar 16, 2011 at 6:26 PM, Luigi Calori l.cal...@cineca.it wrote:
On 16/03/2011 17.37, David Cole wrote:
It would be nice (as a future feature addition) to be able to support
sharing the download/update/patch/source_dir aspects of an
ExternalProject target among multiple configurations and avoid the
multiple runs of these things that are exactly the same independent of
the config.
Until that dream becomes reality, though.
I had once modified the External to include support for SRC_STAMP_DIR
# [SRCSTAMP_DIR dir] # Directory to store source step timestamps
I still have the file but i unfortunated did not kept it up to date with
recent mods
You could run a script as the PATCH_COMMAND, and put some sort of has
this patch already been applied to this source tree logic into the
script, and only actually do the patch command if not already applied.
It's a work-around, and might be ugly, but it should work.
Another way is to split the project in two:
one build the source and the other do the config,build,install like
ExternalProject_Add(
${PACKAGE}-GetSource
SOURCE_DIR ${Package_Source_Dir}
STAMP_DIR ${Package_Source_Stamp_Dir}
--- I set this in a place
near the sources, so can remove the build without re-patch
SVN_REPOSITORY
PATCH_COMMAND - your patch---
UPDATE_COMMAND
CONFIGURE_COMMAND
BUILD_COMMAND
INSTALL_COMMAND
)
if(Package_current_dependencies_effective_line)
set( Package_current_dependencies_effective_line
${Package_current_dependencies_effective_line} ${PACKAGE}-GetSource)
else()
set(Package_current_dependencies_effective_line DEPENDS
${PACKAGE}-GetSource)
endif()
ExternalProject_Add(
${PACKAGE}
SOURCE_DIR ${Package_Source_Dir}
DOWNLOAD_COMMAND --this is
important
BUILD_DIR ..
INSTALL_DIR
CMAKE_COMMAND ${CMAKE_COMMAND}
CMAKE_ARGS
${Package_std_cmake_args}
${Package_additional_cmake_args}
BUILD_COMMAND
INSTALL_COMMAND
${Package_current_dependencies_effective_line}
add ${PACKAGE}-GetSource to your dependencies
STEP_TARGETS configure build
)
HTH
Luigi
HTH,
David
On Wed, Mar 16, 2011 at 11:40 AM, Johan Björkp...@spotify.com wrote:
Hi everyone,
I'm using an SVN repository and a PATCH command. It seems to work
fine, but when I'm selecting a different build configuration, all
steps will be executed again (as expected), but it results in my patch
being applied twice.
Any ideas how to work around this?
My externalProject command for reference:
ExternalProject_Add(Breakpad
SVN_REPOSITORY http://google-breakpad.googlecode.com/svn/trunk/
UPDATE_COMMAND
CMAKE_ARGS -DCMAKE_INSTALL_PREFIX:PATH=INSTALL_DIR
-DCMAKE_OSX_DEPLOYMENT_TARGET:STRING=${CMAKE_OSX_DEPLOYMENT_TARGET}
-DCMAKE_OSX_ARCHITECTURES:STRING=${CMAKE_OSX_ARCHITECTURES}
PATCH_COMMAND patch
${CMAKE_CURRENT_LIST_DIR}/other/patches/breakpad.patch
)
Thanks
/Johan
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Johan Björk
Team Lead, Development Tools
Spotify AB
Address: Birger Jarlsgatan 6, 114 46 Stockholm, Sweden
Phone:+46 (0)709 22 59
Re: [CMake] Ninja: a small build system closest in spirit to Make
On Mon, Feb 14, 2011 at 9:39 PM, Bill Hoffman bill.hoff...@kitware.com wrote:
On 2/14/2011 3:37 PM, Jean-Christophe Fillion-Robin wrote:
Last night, I started a topic named ninja-generator on my github ...
see https://github.com/jcfr/CMake/tree/ninja-generator
Right now, I just copied all the file related to CMakefile generator and
named using the Ninja prefix.
I think we should submit patches to Ninja using Github since it has
been published there. For submitting patches to CMake, I think it is
better to follow its regular workflow.
Is that the right approach ? Comment from CMake Internals experts are
welcome :)
Thanks
This should move to the cmake-developers mailing list.
I have started a new thread on this mailing list.
-Nico
Jc
On Sun, Feb 13, 2011 at 12:19 PM, Caner Candan ca...@candan.fr
mailto:ca...@candan.fr wrote:
You are followed :) great job!
On Sat, Feb 12, 2011 at 2:15 PM, Jean-Christophe Fillion-Robin
jchris.filli...@kitware.com mailto:jchris.filli...@kitware.com
wrote:
I forked the original ninja project on my github and cmake'ified it.
It successfully compile on linux [ubuntu 10.04, g++ (Ubuntu
4.4.3-4ubuntu5)
4.4.3]
Note that both In and Out-of-source built are handled properly.
See https://github.com/jcfr/ninja topic branch: cmakeified-project
git clone git://github.com/jcfr/ninja.git
http://github.com/jcfr/ninja.git
mkdir ninja-build
cd ninja-build
cmake ../ninja make
I also added the option BUILD_TESTING, by default enabled.
Running ctest, a test named LongSlowBuild will proceed.
This test invoke the following command:
ninja -f SRC/misc/long-slow-build.ninja all
The associated dashboard is available on my.cdash.org
http://my.cdash.org.
See http://my.cdash.org/index.php?project=ninja
I submitted some experimentals dashboards ...
- Linux: build and test pass
- Windows: doesn't compile. See
http://my.cdash.org/buildSummary.php?buildid=155950
... and also setup a nightly for both windows and linux.
(Template dashboard
script here)
Note that I fix some of the windows error. Changes are in the topic
fix-windows-build of github.com:jcfr/ninja.git
Most of the remaining errors are listed here:
http://my.cdash.org/viewBuildError.php?buildid=156132
Thks
Jc
On Fri, Feb 11, 2011 at 9:59 PM, Clifford Yapp
cliffy...@gmail.com mailto:cliffy...@gmail.com wrote:
We could start with the CMakeLists.txt file :-).
It doesn't want to do an out of source dir build either, have to
see
why...
On Fri, Feb 11, 2011 at 9:58 AM, David Cole
david.c...@kitware.com mailto:david.c...@kitware.com
wrote:
I tried compiling it on Windows yesterday with just the following
CMakeLists.txt file, and there were a bunch of compile errors. It
shouldn't
be too hard to make it work on Windows, though, if Mr. Martin
will
accept
some patches for it... :-)
cmake_minimum_required(VERSION 2.8)
project(ninja)
set(ninja_lib_sources
src/build.cc
src/build_log.cc
src/eval_env.cc
src/graph.cc
src/parsers.cc
src/subprocess.cc
src/util.cc
src/ninja_jumble.cc
)
add_library(ninjaLib STATIC ${ninja_lib_sources})
add_executable(ninja src/ninja.cc)
target_link_libraries(ninja ninjaLib)
Cheers,
David
___
Powered by www.kitware.com http://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
Powered by www.kitware.com http://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
--
Direct: 1-518-836-2174
Ext: 304
___
Powered by www.kitware.com http://www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and
Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to That did it Thanks, Michael. That's exactly what I needed. It's somewhat moot now, but your second suggestion confused me, and I'd like to understand better: As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) Two questions: 1. Does a second invocation override the first invocation? 2. If I remove the VTK libs from this command, wouldn't that leave FeatureViewer with unresolved symbols? Thanks again for your help!! -Chris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Hertling Sent: Tuesday, March 22, 2011 7:30 PM To: cmake@cmake.org Subject: Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design? [my original elided for brevity --CRV] The TARGET_LINK_LIBRARIES() command works transitively, i.e. TestDriver will be linked against each shared library that FeatureViewer is linked against, too. You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to or, in general, to the set of libraries which are still to be linked transitively. As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) in FeatureViewer/CMakeLists.txt to explicitly specify the transitive libraries. Of course, the VTK ones should not appear in these lists. 'hope that helps. Regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
Jc-
Thanks for the suggestions, but it's not clear if your suggestions are general
suggestions, or if they actually address the problem I'm experiencing.
Moreover, the problems that your suggestions claim to solve seem to be problems
that I am not experiencing.
For example, you write:
After being executed, this later one will allow you to include VTK header files
from files associated with FeatureViewer target and targets located in
subdirectories. For example tests.
This is precisely what I *don't* want to do. I want to hide VTK's usage
completely from clients of FeatureViewer. I do not want clients of
FeatureViewer to have to include VTK headers or link against VTK libraries. Of
course, the VTK dlls will be available at runtime for FeatureViewer to load,
but that doesn't affect the client's compilation or linking process.
Also:
Moreover, in your example, it seems the command LINK_DIRECTORIES is missing.
Indeed, you should add the following command before calling
ADD_LIBRARY(FeatureViewer ...):
LINK_DIRECTORIES(${VTK_LIBRARY_DIRS})
What problem does LINK_DIRECTORIES solve? Note that I have no problem
building FeatureViewer: It finds the VTK libraries just fine without
LINK_DIRECTORIES. Again, the TestDriver application builds and runs just fine
if I manually remove the references to vtk*.lib in its project settings.
thanks,
-Chris
Chris
--
Christopher R. Volpe, Ph.D.
Email: cvo...@ara.commailto:cvo...@ara.com
Senior Scientist, Information Exploitation Systems Main Desk:
919-582-3300
Applied Research Associates, Inchttp://www.ara.com/
Direct: 919-582-3380
8537 Six Forks Rd., Suite 6000
Fax : 919-582-3301
Raleigh, NC 27615 Web:
http://www.ara.com/offices/NC.htm
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
On 03/23/2011 03:21 PM, Chris Volpe ARA/SED wrote: You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to That did it Thanks, Michael. That's exactly what I needed. It's somewhat moot now, but your second suggestion confused me, and I'd like to understand better: As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) Oops: TARGET_LINK_LIBRARIES(FeatureViewer LINK_INTERFACE_LIBRARIES ...) Two questions: 1. Does a second invocation override the first invocation? 2. If I remove the VTK libs from this command, wouldn't that leave FeatureViewer with unresolved symbols? No, for both questions. Each shared library target has a set of transitive libraries, i.e. libraries other targets are additionally linked against if they are linked against the shared library target. As a default, this set consists of those libraries mentioned in the shared library target's TARGET_LINK_LIBRARIES() command invocation. Nevertheless, if the LINK_INTERFACE_LIBRARIES target property has a defined value, this is used for the set of transitive libraries. Now, TARGET_LINK_LIBRARIES() with the LINK_INTERFACE_LIBRARIES clause just adds the specified libraries to the aforementioned property without an impact on the libraries the target is actually linked against. Hence, a second invocation with LINK_INTERFACE_LIBRARIES clause would affect the TestDriver and further depending targets, but not the FeatureViewer one. Regards, Michael Thanks again for your help!! -Chris -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Michael Hertling Sent: Tuesday, March 22, 2011 7:30 PM To: cmake@cmake.org Subject: Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design? [my original elided for brevity --CRV] The TARGET_LINK_LIBRARIES() command works transitively, i.e. TestDriver will be linked against each shared library that FeatureViewer is linked against, too. You might break this transitivity by explicitly setting the LINK_INTERFACE_LIBRARIES target properties of FeatureViewer to or, in general, to the set of libraries which are still to be linked transitively. As an alternative, you might use a second invocation TARGET_LINK_LIBRARIES(FeatureViewer TARGET_LINK_LIBRARIES ...) in FeatureViewer/CMakeLists.txt to explicitly specify the transitive libraries. Of course, the VTK ones should not appear in these lists. 'hope that helps. Regards, Michael ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Building a DLL and test driver EXE using CMake -- error by design?
On 03/23/2011 05:26 PM, Chris Volpe ARA/SED wrote:
Jc-
Thanks for the suggestions, but it's not clear if your suggestions are
general suggestions, or if they actually address the problem I'm
experiencing. Moreover, the problems that your suggestions claim to solve
seem to be problems that I am not experiencing.
[...]
Also:
Moreover, in your example, it seems the command LINK_DIRECTORIES is
missing. Indeed, you should add the following command before calling
ADD_LIBRARY(FeatureViewer ...):
LINK_DIRECTORIES(${VTK_LIBRARY_DIRS})
What problem does LINK_DIRECTORIES solve? Note that I have no problem
building FeatureViewer: It finds the VTK libraries just fine without
LINK_DIRECTORIES. Again, the TestDriver application builds and runs just fine
if I manually remove the references to vtk*.lib in its project settings.
LINK_DIRECTORIES() can be subtly dangerous, see [1], so it should not
be used if it's avoidable. AFAICS, VTK uses imported targets for its
libraries, i.e. with full paths in the libraries' IMPORTED_LOCATION
properties, so there shouldn't be a need to use LINK_DIRECTORIES()
w.r.t. VTK.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg33519.html
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v2.8.4-1253-gfb46ce9
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 fb46ce90910995e3096a1c9b415fed35dbdcd79b (commit)
via c2bf48ef57a9ded10c4e8470e56d0dbdcdb51284 (commit)
via 11431c67c6ec6c545d23b9615cb8dd249b4c3aaa (commit)
via a262fe0917364cb003f7319b3d17c46280d75927 (commit)
from 9994cb432946f0f5e07dab14ed0d06d3c4e5602c (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fb46ce90910995e3096a1c9b415fed35dbdcd79b
commit fb46ce90910995e3096a1c9b415fed35dbdcd79b
Merge: 9994cb4 c2bf48e
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Mar 23 14:43:10 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Wed Mar 23 14:43:10 2011 -0400
Merge topic 'gnu-install-dirs-issue-3976' into next
c2bf48e GNUInstallDirs: Propagate DATAROOTDIR changes to dependent defaults
11431c6 GNUInstallDirs: Simplify and clarify documentation
a262fe0 Add GNUInstallDirs module to define GNU layout (#3976)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c2bf48ef57a9ded10c4e8470e56d0dbdcdb51284
commit c2bf48ef57a9ded10c4e8470e56d0dbdcdb51284
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Feb 25 12:28:52 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Mar 23 14:39:05 2011 -0400
GNUInstallDirs: Propagate DATAROOTDIR changes to dependent defaults
diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake
index bd85e1d..bb651de 100644
--- a/Modules/GNUInstallDirs.cmake
+++ b/Modules/GNUInstallDirs.cmake
@@ -84,26 +84,38 @@ if(NOT DEFINED CMAKE_INSTALL_DATAROOTDIR)
set(CMAKE_INSTALL_DATAROOTDIR share CACHE PATH read-only
architecture-independent data root (share))
endif()
-if(NOT DEFINED CMAKE_INSTALL_DATADIR)
- set(CMAKE_INSTALL_DATADIR ${CMAKE_INSTALL_DATAROOTDIR} CACHE PATH
read-only architecture-independent data (DATAROOTDIR))
+#-
+# Values whose defaults are relative to DATAROOTDIR. Store empty values in
+# the cache and store the defaults in local variables if the cache values are
+# not set explicitly. This auto-updates the defaults as DATAROOTDIR changes.
+
+if(NOT CMAKE_INSTALL_DATADIR)
+ set(CMAKE_INSTALL_DATADIR CACHE PATH read-only architecture-independent
data (DATAROOTDIR))
+ set(CMAKE_INSTALL_DATADIR ${CMAKE_INSTALL_DATAROOTDIR})
endif()
-if(NOT DEFINED CMAKE_INSTALL_INFODIR)
- set(CMAKE_INSTALL_INFODIR ${CMAKE_INSTALL_DATAROOTDIR}/info CACHE PATH
info documentation (DATAROOTDIR/info))
+if(NOT CMAKE_INSTALL_INFODIR)
+ set(CMAKE_INSTALL_INFODIR CACHE PATH info documentation
(DATAROOTDIR/info))
+ set(CMAKE_INSTALL_INFODIR ${CMAKE_INSTALL_DATAROOTDIR}/info)
endif()
-if(NOT DEFINED CMAKE_INSTALL_LOCALEDIR)
- set(CMAKE_INSTALL_LOCALEDIR ${CMAKE_INSTALL_DATAROOTDIR}/locale CACHE PATH
locale-dependent data (DATAROOTDIR/locale))
+if(NOT CMAKE_INSTALL_LOCALEDIR)
+ set(CMAKE_INSTALL_LOCALEDIR CACHE PATH locale-dependent data
(DATAROOTDIR/locale))
+ set(CMAKE_INSTALL_LOCALEDIR ${CMAKE_INSTALL_DATAROOTDIR}/locale)
endif()
-if(NOT DEFINED CMAKE_INSTALL_MANDIR)
- set(CMAKE_INSTALL_MANDIR ${CMAKE_INSTALL_DATAROOTDIR}/man CACHE PATH man
documentation (DATAROOTDIR/man))
+if(NOT CMAKE_INSTALL_MANDIR)
+ set(CMAKE_INSTALL_MANDIR CACHE PATH man documentation (DATAROOTDIR/man))
+ set(CMAKE_INSTALL_MANDIR ${CMAKE_INSTALL_DATAROOTDIR}/man)
endif()
-if(NOT DEFINED CMAKE_INSTALL_DOCDIR)
- set(CMAKE_INSTALL_DOCDIR ${CMAKE_INSTALL_DATAROOTDIR}/doc/${PROJECT_NAME}
CACHE PATH documentation root (DATAROOTDIR/doc/PROJECT_NAME))
+if(NOT CMAKE_INSTALL_DOCDIR)
+ set(CMAKE_INSTALL_DOCDIR CACHE PATH documentation root
(DATAROOTDIR/doc/PROJECT_NAME))
+ set(CMAKE_INSTALL_DOCDIR ${CMAKE_INSTALL_DATAROOTDIR}/doc/${PROJECT_NAME})
endif()
+#-
+
mark_as_advanced(
CMAKE_INSTALL_BINDIR
CMAKE_INSTALL_SBINDIR
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=11431c67c6ec6c545d23b9615cb8dd249b4c3aaa
commit 11431c67c6ec6c545d23b9615cb8dd249b4c3aaa
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Feb 25 12:21:22 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Mon Feb 28 15:15:01 2011 -0500
GNUInstallDirs: Simplify and clarify documentation
diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake
index 8bed2e9..bd85e1d 100644
--- a/Modules/GNUInstallDirs.cmake
+++ b/Modules/GNUInstallDirs.cmake
@@ -1,53 +1,36 @@
-# - Define the installation directories conforming to GNU standards.
-# This module
[Cmake-commits] CMake branch, next, updated. v2.8.4-1255-g02b69e6
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 02b69e6f7df2b92a418946094685eb88542e10fa (commit) via 7afcb8103793b6cb4dc3243732cc5cf4aa85c8b9 (commit) from fb46ce90910995e3096a1c9b415fed35dbdcd79b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=02b69e6f7df2b92a418946094685eb88542e10fa commit 02b69e6f7df2b92a418946094685eb88542e10fa Merge: fb46ce9 7afcb81 Author: Brad King brad.k...@kitware.com AuthorDate: Wed Mar 23 15:01:21 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Mar 23 15:01:21 2011 -0400 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.4-1257-g6b14f90
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 6b14f9017e2bf851527fbef24dbbb3cea14649d1 (commit) via 945f2c2214bc80f513ed08ebe2c8003263a4ee56 (commit) from 02b69e6f7df2b92a418946094685eb88542e10fa (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6b14f9017e2bf851527fbef24dbbb3cea14649d1 commit 6b14f9017e2bf851527fbef24dbbb3cea14649d1 Merge: 02b69e6 945f2c2 Author: Bill Hoffman bill.hoff...@kitware.com AuthorDate: Wed Mar 23 15:11:53 2011 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Wed Mar 23 15:11:53 2011 -0400 Merge topic 'fix_long_filenames_vs2010' into next 945f2c2 With very long file names, VS 2010 was unable to compile files. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=945f2c2214bc80f513ed08ebe2c8003263a4ee56 commit 945f2c2214bc80f513ed08ebe2c8003263a4ee56 Author: Bill Hoffman bill.hoff...@kitware.com AuthorDate: Wed Mar 23 15:06:44 2011 -0400 Commit: Bill Hoffman bill.hoff...@kitware.com CommitDate: Wed Mar 23 15:06:44 2011 -0400 With very long file names, VS 2010 was unable to compile files. At some point in the past VS 2010 failed some tests with custom commands when relative paths were not used. It seems that those problems have been fixed. However, the relative paths apparently are appended to the current working directoy before vs accesses the file. So, with a long path, relative paths cause it to create a combined path that is too long. diff --git a/Source/cmVisualStudio10TargetGenerator.cxx b/Source/cmVisualStudio10TargetGenerator.cxx index 8a27ffd..f872838 100644 --- a/Source/cmVisualStudio10TargetGenerator.cxx +++ b/Source/cmVisualStudio10TargetGenerator.cxx @@ -367,10 +367,7 @@ cmVisualStudio10TargetGenerator::WriteCustomRule(cmSourceFile* source, static_castcmGlobalVisualStudio7Generator * (this-GlobalGenerator)-GetConfigurations(); this-WriteString(CustomBuild Include=\, 2); - std::string path = -cmSystemTools::RelativePath( - this-Makefile-GetCurrentOutputDirectory(), - sourcePath.c_str()); + std::string path = sourcePath; this-ConvertToWindowsSlash(path); (*this-BuildFileStream ) path \\n; for(std::vectorstd::string::iterator i = configs-begin(); @@ -609,9 +606,6 @@ WriteGroupSources(const char* name, const char* filter = sourceGroup.GetFullName(); this-WriteString(, 2); std::string path = source; -path = cmSystemTools::RelativePath( - this-Makefile-GetCurrentOutputDirectory(), - source.c_str()); this-ConvertToWindowsSlash(path); (*this-BuildFileStream) name Include=\ path; @@ -685,9 +679,6 @@ void cmVisualStudio10TargetGenerator::WriteCLSources() bool rc = lang (strcmp(lang, RC) == 0); bool idl = ext == idl; std::string sourceFile = (*source)-GetFullPath(); -sourceFile = cmSystemTools::RelativePath( - this-Makefile-GetCurrentOutputDirectory(), - sourceFile.c_str()); this-ConvertToWindowsSlash(sourceFile); // output the source file if(header) --- Summary of changes: Source/cmVisualStudio10TargetGenerator.cxx | 11 +-- 1 files changed, 1 insertions(+), 10 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.4-248-g29487ba
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 29487baceadc3c416178d325a9656c9d68c53972 (commit)
from 7afcb8103793b6cb4dc3243732cc5cf4aa85c8b9 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=29487baceadc3c416178d325a9656c9d68c53972
commit 29487baceadc3c416178d325a9656c9d68c53972
Author: Brad King brad.k...@kitware.com
AuthorDate: Wed Mar 23 17:09:46 2011 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Wed Mar 23 17:20:04 2011 -0400
KWSys: Do not trust EXECUTABLE_OUTPUT_PATH for ProcessFwd9x encoding
Set target property RUNTIME_OUTPUT_DIRECTORY explicitly on ProcessFwd9x
and EncodeExecutable so that we know exactly where the executables will
exist on disk.
diff --git a/Source/kwsys/CMakeLists.txt b/Source/kwsys/CMakeLists.txt
index f5f317c..0ef4e28 100644
--- a/Source/kwsys/CMakeLists.txt
+++ b/Source/kwsys/CMakeLists.txt
@@ -847,23 +847,19 @@ IF(KWSYS_USE_Process)
# encode it into a C file.
ADD_EXECUTABLE(${KWSYS_NAMESPACE}ProcessFwd9x ProcessFwd9x.c)
ADD_EXECUTABLE(${KWSYS_NAMESPACE}EncodeExecutable EncodeExecutable.c)
+SET_PROPERTY(TARGET ${KWSYS_NAMESPACE}ProcessFwd9x PROPERTY
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
+SET_PROPERTY(TARGET ${KWSYS_NAMESPACE}EncodeExecutable PROPERTY
RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
SET_PROPERTY(TARGET ${KWSYS_NAMESPACE}ProcessFwd9x PROPERTY LABELS
${KWSYS_LABELS_EXE})
SET_PROPERTY(TARGET ${KWSYS_NAMESPACE}EncodeExecutable PROPERTY LABELS
${KWSYS_LABELS_EXE})
-# Construct the location of the executable to be encoded.
-SET(BIN_DIR ${CMAKE_CURRENT_BINARY_DIR})
-IF(EXECUTABLE_OUTPUT_PATH)
- SET(BIN_DIR ${EXECUTABLE_OUTPUT_PATH})
-ENDIF(EXECUTABLE_OUTPUT_PATH)
-
SET(CFG_INTDIR /${CMAKE_CFG_INTDIR})
IF(CMAKE_BUILD_TOOL MATCHES make)
SET(CFG_INTDIR )
ENDIF(CMAKE_BUILD_TOOL MATCHES make)
# Take advantage of a better custom command syntax if possible.
-SET(CMD ${BIN_DIR}${CFG_INTDIR}/${KWSYS_NAMESPACE}EncodeExecutable.exe)
-SET(FWD ${BIN_DIR}${CFG_INTDIR}/${KWSYS_NAMESPACE}ProcessFwd9x.exe)
+SET(CMD
${CMAKE_CURRENT_BINARY_DIR}${CFG_INTDIR}/${KWSYS_NAMESPACE}EncodeExecutable.exe)
+SET(FWD
${CMAKE_CURRENT_BINARY_DIR}${CFG_INTDIR}/${KWSYS_NAMESPACE}ProcessFwd9x.exe)
ADD_CUSTOM_COMMAND(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/${KWSYS_NAMESPACE}ProcessFwd9xEnc.c
COMMAND ${CMD}
---
Summary of changes:
Source/kwsys/CMakeLists.txt | 12
1 files changed, 4 insertions(+), 8 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.4-1259-g1fe87de
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 1fe87deb6db89a50441874ebca6a421992da4f73 (commit) via 29487baceadc3c416178d325a9656c9d68c53972 (commit) from 6b14f9017e2bf851527fbef24dbbb3cea14649d1 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1fe87deb6db89a50441874ebca6a421992da4f73 commit 1fe87deb6db89a50441874ebca6a421992da4f73 Merge: 6b14f90 29487ba Author: Brad King brad.k...@kitware.com AuthorDate: Wed Mar 23 17:23:40 2011 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Wed Mar 23 17:23:40 2011 -0400 Merge branch 'master' into next --- Summary of changes: Source/kwsys/CMakeLists.txt | 12 1 files changed, 4 insertions(+), 8 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
