[cmake-developers] [CMake 0012062]: CPackDeb: The EXTRA control files may not be specified on a per-component basis
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12062
==
Reported By:Eric NOULARD
Assigned To:
==
Project:CMake
Issue ID: 12062
Category: CPack
Reproducibility:have not tried
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2011-04-09 09:48 CEST
Last Modified: 2011-04-09 09:48 CEST
==
Summary:CPackDeb: The EXTRA control files may not be
specified on a per-component basis
Description:
CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA may be used to add user specified
control file to the .deb.
Currently one cannot specify a component specific Control file.
# CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
# This variable allow advanced user to add custom script to the control.tar.gz
(inside the .deb archive)
# Typical examples are:
# - conffiles
# - postinst
# - postrm
# - prerm
# Usage:
# SET(CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA
#${CMAKE_CURRENT_SOURCE_DIR/prerm;${CMAKE_CURRENT_SOURCE_DIR}/postrm)
==
Issue History
Date ModifiedUsername FieldChange
==
2011-04-09 09:48 Eric NOULARD New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0012065]: file(RELATIVE_PATH ...) gives wrong results with extra ./
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=12065
==
Reported By:Clinton Stimpson
Assigned To:
==
Project:CMake
Issue ID: 12065
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-04-09 17:59 EDT
Last Modified: 2011-04-09 17:59 EDT
==
Summary:file(RELATIVE_PATH ...) gives wrong results with
extra ./
Description:
set(fil /path/to/one)
set(dir /path/to/.)
file(RELATIVE_PATH rel ${dir} ${fil})
message(STATUS rel=${rel})
# output is rel=../one -- wrong
set(dir /path/to/././././.)
# with get_filename_component it gives the rel=one instead of
# rel=../../../../../one
get_filename_component(dir /path/to/././././. ABSOLUTE)
file(RELATIVE_PATH rel ${dir} ${fil})
message(STATUS rel=${rel})
==
Issue History
Date ModifiedUsername FieldChange
==
2011-04-09 17:59 Clinton StimpsonNew Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Target visibility in CMake using Xcode generator
Dear all,
I have an issue with the Xcode generator and the visibility of targets
in the generated project files. The problem is that in the project
files generated in subdirectories, targets from the directories above
are not visible.
At the bottom of the email, you can see the project structure and code
files. The setup is as follows: A is the project root, B is a
subdirectory, each directory contains a CMakeLists.txt.
A/CMakeLists.txt creates a target target_a and a custom command that
creates a file target_ab by touching it. target_a depends on the file
target_ab and thus when target_a is built, the file is created. B/
CMakeLists.txt contains a target for an executable target_b that
depends on target_a and includes the generated file A/target_ab.
Thus, when generate Makefiles, I can type make target_b and this
will automatically build target_a and create file target_ab. This
works in a clean out-of-source build directory both from directories
the root and subdirectory B.
I then generate an Xcode project in an out-of-source build. I can
build target_b without any problems from the A.xcodeproj. This will
also create file target_ab. However, when I start with a clean build
directory, generate XCode project, open B/B.xcodeproj and try to build
target_b, then target_a does not appear in the target list, target_b
thus does not depend on it (I guess) and subsequently, the file
target_ab is not generated!
Is this behaviour desired/expected? Given that the Makefiles generator
works fine for my use case, I would expect that target_a is also
visible in B.xcodeproj. I would expect that either all targets should
be visible the generated projects in subdirectories or at least the
targets required to build the subdirectories.
Bests,
Manuel
$ tree A
A
├── B
│ ├── CMakeLists.txt
│ └── target_b.cpp
├── CMakeLists.txt
└── target_aa.cpp
1 directory, 4 files
$ cat A/target_aa.cpp
int main(int argc, char **argv)
{
return 0;
}
$ cat A/B/target_b.cpp
#include ../target_ab
int main(int argc, char **argv)
{
return 0;
}
$ cat A/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(A)
add_executable(target_aa target_aa.cpp)
add_custom_command(OUTPUT target_ab COMMAND touch target_ab)
add_custom_target(target_a DEPENDS target_aa target_ab)
add_subdirectory(B)
$ cat A/B/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(B)
include_directories(${CMAKE_CURRENT_BINARY_DIR})
add_executable(target_b target_b.cpp)
add_dependencies(target_b target_a)
___
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] Target visibility in CMake using Xcode generator
On 04/09/2011 01:43 PM, Manuel Holtgrewe wrote:
Dear all,
I have an issue with the Xcode generator and the visibility of targets
in the generated project files. The problem is that in the project
files generated in subdirectories, targets from the directories above
are not visible.
At the bottom of the email, you can see the project structure and code
files. The setup is as follows: A is the project root, B is a
subdirectory, each directory contains a CMakeLists.txt.
A/CMakeLists.txt creates a target target_a and a custom command that
creates a file target_ab by touching it. target_a depends on the file
target_ab and thus when target_a is built, the file is created. B/
CMakeLists.txt contains a target for an executable target_b that
depends on target_a and includes the generated file A/target_ab.
Thus, when generate Makefiles, I can type make target_b and this
will automatically build target_a and create file target_ab. This
works in a clean out-of-source build directory both from directories
the root and subdirectory B.
I then generate an Xcode project in an out-of-source build. I can
build target_b without any problems from the A.xcodeproj. This will
also create file target_ab. However, when I start with a clean build
directory, generate XCode project, open B/B.xcodeproj and try to build
target_b, then target_a does not appear in the target list, target_b
thus does not depend on it (I guess) and subsequently, the file
target_ab is not generated!
Is this behaviour desired/expected? Given that the Makefiles generator
works fine for my use case, I would expect that target_a is also
visible in B.xcodeproj. I would expect that either all targets should
be visible the generated projects in subdirectories or at least the
targets required to build the subdirectories.
Bests,
Manuel
$ tree A
A
├── B
│ ├── CMakeLists.txt
│ └── target_b.cpp
├── CMakeLists.txt
└── target_aa.cpp
1 directory, 4 files
$ cat A/target_aa.cpp
int main(int argc, char **argv)
{
return 0;
}
$ cat A/B/target_b.cpp
#include ../target_ab
int main(int argc, char **argv)
{
return 0;
}
$ cat A/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(A)
add_executable(target_aa target_aa.cpp)
add_custom_command(OUTPUT target_ab COMMAND touch target_ab)
add_custom_target(target_a DEPENDS target_aa target_ab)
add_subdirectory(B)
$ cat A/B/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(B)
include_directories(${CMAKE_CURRENT_BINARY_DIR})
add_executable(target_b target_b.cpp)
add_dependencies(target_b target_a)
There're two spots in your A/CMakeLists.txt catching my eye, although I
doubt that they are actually causing the difficulties you report on:
1) The DEPENDS clause of ADD_CUSTOM_TARGET() is meant for file-level
dependencies only, i.e. you shouldn't denote a target as target_aa
but files and particularly OUTPUTs of custom commands as target_ab
after that clause. Instead, you should use ADD_DEPENDENCIES() to
establish a dependency of target_a on target_aa.
2) When dealing with custom commands' OUTPUTs, it's best to specify
full paths since it is hardly documented how relative paths are
interpreted, i.e. relative to the source directory or the build
tree. AFAIK, it's ADD_CUSTOM_COMMAND(OUTPUT ...) only that - in
a documented manner - interprets a relative OUTPUT path w.r.t.
to CMAKE_CURRENT_BINARY_DIR.
Having said that, with a Makefile generator, your projects A and B
indeed work as one would usually expect, despite the limitation of
the ADD_CUSTOM_TARGET() command's DEPENDS clause mentioned in the
documentation, but perhaps, the Xcode generator or Xcode itself
is pickier.
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] Bug fix requests for the *next* release of CMake...
http://public.kitware.com/Bug/view.php?id=11690 XCode user settings
http://public.kitware.com/Bug/view.php?id=11692 interrupt batch build
doesn't stop visual studio
http://public.kitware.com/Bug/view.php?id=10039 Xcode gen only creates one
level of group nesting
http://public.kitware.com/Bug/view.php?id=11844 Xcode depends helper works
badly. But prefer to remove dep helper completely.
http://public.kitware.com/Bug/view.php?id=11667 - this bug is already fixed
and should be closed.
http://public.kitware.com/Bug/view.php?id=8179 - dup of above
-Johan
On Fri, Apr 1, 2011 at 2:18 AM, Chris Scharver schar...@gmail.com wrote:
On Thu, Mar 31, 2011 at 6:39 PM, Bill Hoffman bill.hoff...@kitware.com
wrote:
On 3/31/2011 6:15 PM, David Cole wrote:
On Thu, Mar 31, 2011 at 6:05 PM, Bill Hoffman bill.hoff...@kitware.com
mailto:bill.hoff...@kitware.com wrote:
On 3/31/2011 4:19 PM, Chris Scharver wrote:
EXTERNAL_OBJECT not linked using Visual Studio 2010
http://public.kitware.com/Bug/view.php?id=11891
Thanks for the pointer to that bug. It even has a fix. The thing I
can not figure out is why our ExternlObj test is passing even when
this is broken Any ideas why that test works?
I think it's one of those works in MSBuild, but not in devenv
issues...
Nope, I loaded it up in devenv and ExternlObj compiles Ran cmake-gui
on
ExternalObj then loaded the project and it works... ???
I just did some tinkering and found that a simple change of modifying
the ExternalObj test to link with the external object resulted in a
failure.
ADD_EXECUTABLE(ExternalOBJ executable.cxx ${EXTERNAL_OBJECT})
SET_SOURCE_FILES_PROPERTIES(${EXTERNAL_OBJECT} PROPERTIES EXTERNAL_OBJECT
1)
Perhaps the fact that there's a rule to generate the custom object
changes how it's handled?
Chris
___
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] Target visibility in CMake using Xcode generator
There're two spots in your A/CMakeLists.txt catching my eye,
although I
doubt that they are actually causing the difficulties you report on:
1) The DEPENDS clause of ADD_CUSTOM_TARGET() is meant for file-level
dependencies only, i.e. you shouldn't denote a target as target_aa
but files and particularly OUTPUTs of custom commands as target_ab
after that clause. Instead, you should use ADD_DEPENDENCIES() to
establish a dependency of target_a on target_aa.
2) When dealing with custom commands' OUTPUTs, it's best to specify
full paths since it is hardly documented how relative paths are
interpreted, i.e. relative to the source directory or the build
tree. AFAIK, it's ADD_CUSTOM_COMMAND(OUTPUT ...) only that - in
a documented manner - interprets a relative OUTPUT path w.r.t.
to CMAKE_CURRENT_BINARY_DIR.
Having said that, with a Makefile generator, your projects A and B
indeed work as one would usually expect, despite the limitation of
the ADD_CUSTOM_TARGET() command's DEPENDS clause mentioned in the
documentation, but perhaps, the Xcode generator or Xcode itself
is pickier.
I changed the CMakeLists.txt files as can bee seen at the bottom of
the email. I hope this resolves both points you described above.
However, the problem persists.
Is this the limitation you mention: Dependencies listed with the
DEPENDS argument may reference files and outputs of custom commands
created with add_custom_command() in the same directory
(CMakeLists.txt file).? The way I understand it, my
add_custom_target() statement references only files generated in the
same CMakeLists.txt. The documentation does not explicitely limit a
target from another CMakeLists.txt file depending indirectly on
generated files.
To clarify whether the problem is in Xcode or the generator, I grepped
for target_ab in a build directory for Xcode and one for Makefiles.
The results can also be found at the bottom of the email. As can be
seen, target_ab does not occur in combination with target_b. I also
grepped for target_a (the results are ommitted for their longness)
and target_a does not occur in any files related to target_b either.
So it appears that the Xcode generator does not realize that I want it
to build target_a when building target_b in the B.xcodeproj file.
The question now is whether there is a way to tell the generator to do
what I want. If it is not possible to do so: Would extending the
generator to do what I want be correct or am I asking for something
that should not be supported?
Bests,
Manuel
$ cat CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(A)
add_executable(target_aa target_aa.cpp)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/target_ab
COMMAND touch ${CMAKE_CURRENT_BINARY_DIR}/target_ab)
add_custom_target(target_a DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/
target_ab)
add_dependencies(target_a target_aa)
add_subdirectory(B)
$ cat B/CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(B)
include_directories(${CMAKE_CURRENT_BINARY_DIR})
add_executable(target_b target_b.cpp)
add_dependencies(target_b target_a)
Makefiles $ grep -Ri target_ab .
./B/CMakeFiles/target_b.dir/CXX.includecache:../target_ab
./B/CMakeFiles/target_b.dir/CXX.includecache:/Users/manuel/Development/
Sandbox/CMakeSandbox/A/B/../target_ab
./B/CMakeFiles/target_b.dir/CXX.includecache:B/../target_ab
./B/CMakeFiles/target_b.dir/depend.internal: B/../target_ab
./B/CMakeFiles/target_b.dir/depend.make:B/CMakeFiles/target_b.dir/
target_b.cpp.o: B/../target_ab
./CMakeFiles/CMakeRuleHashes.txt:eb772089b1414de60dae83cdf775c8ef
target_ab
./CMakeFiles/target_a.dir/build.make:CMakeFiles/target_a: target_ab
./CMakeFiles/target_a.dir/build.make:target_ab:
./CMakeFiles/target_a.dir/build.make: @$(CMAKE_COMMAND) -E
cmake_echo_color --switch=$(COLOR) --blue --bold Generating target_ab
./CMakeFiles/target_a.dir/build.make: touch target_ab
./CMakeFiles/target_a.dir/build.make:target_a: target_ab
./CMakeFiles/target_a.dir/cmake_clean.cmake: target_ab
Xcode $ grep -Ri target_ab .
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeDebug: /Users/manuel/
Development/Sandbox/CMakeSandbox/A-build/Xcode/target_ab
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeDebug:/Users/manuel/
Development/Sandbox/CMakeSandbox/A-build/Xcode/target_ab:
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeDebug: touch target_ab
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeMinSizeRel: /Users/
manuel/Development/Sandbox/CMakeSandbox/A-build/Xcode/target_ab
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeMinSizeRel:/Users/
manuel/Development/Sandbox/CMakeSandbox/A-build/Xcode/target_ab:
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeMinSizeRel: touch
target_ab
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeRelease: /Users/
manuel/Development/Sandbox/CMakeSandbox/A-build/Xcode/target_ab
./CMakeScripts/target_a_cmakeRulesBuildPhase.makeRelease:/Users/manuel/
[CMake] could not find cmake module
I am trying to use cmake to compile a program from source code, i am getting this error: CMake Error: Error required internal CMake variable not set, cmake may be not be built correctly. Missing variable is: CMAKE_CXX_COMPILER_ENV_VAR CMake Error: Could not find cmake module file:C:/MinGW/msys/1.0/home/Kristy/CMak eFiles/CMakeCXXCompiler.cmake -- Configuring incomplete, errors occurred! ___ 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-1402-g8983cb1
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 8983cb1d0b9a083ef08b0e338e18d048a741668c (commit)
via b22fcfb0c55ec145a4cf7405120c708fa136d928 (commit)
via 4e9506ac31705f5099f226128b98ae12a4ba9772 (commit)
from c97d814e780fd79a600934092d185cc73ffa9b24 (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=8983cb1d0b9a083ef08b0e338e18d048a741668c
commit 8983cb1d0b9a083ef08b0e338e18d048a741668c
Merge: c97d814 b22fcfb
Author: Eric Noulard eric.noul...@gmail.com
AuthorDate: Sat Apr 9 03:32:06 2011 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Sat Apr 9 03:32:06 2011 -0400
Merge topic 'CPackDeb-fix12061' into next
b22fcfb CPackDeb: Handle dirs for CONTROL_EXTRA correctly when packaging
components
4e9506a KWSys Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b22fcfb0c55ec145a4cf7405120c708fa136d928
commit b22fcfb0c55ec145a4cf7405120c708fa136d928
Author: Martin Konrad kon...@ikp.tu-darmstadt.de
AuthorDate: Sat Apr 9 09:30:19 2011 +0200
Commit: Eric NOULARD eric.noul...@gmail.com
CommitDate: Sat Apr 9 09:30:19 2011 +0200
CPackDeb: Handle dirs for CONTROL_EXTRA correctly when packaging components
Copy the files specified in CPACK_DEBIAN_PACKAGE_CONTROL_EXTRA to the right
directory when packaging components. This fixes #12061.
Signed-off-by: Eric NOULARD eric.noul...@gmail.com
diff --git a/Source/CPack/cmCPackDebGenerator.cxx
b/Source/CPack/cmCPackDebGenerator.cxx
index 5665404..8c19bbd 100644
--- a/Source/CPack/cmCPackDebGenerator.cxx
+++ b/Source/CPack/cmCPackDebGenerator.cxx
@@ -491,7 +491,7 @@ int cmCPackDebGenerator::createDeb()
{
std::string filenamename =
cmsys::SystemTools::GetFilenameName(i-c_str());
- std::string localcopy = toplevel;
+ std::string localcopy = this-GetOption(WDIR);
localcopy += /;
localcopy += filenamename;
// if we can copy the file, it means it does exist, let's add it:
---
Summary of changes:
Source/CPack/cmCPackDebGenerator.cxx |2 +-
Source/kwsys/kwsysDateStamp.cmake|2 +-
2 files changed, 2 insertions(+), 2 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-322-gc2ef7ab
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 c2ef7abe0462ff66151403a9a16b4652886d56cf (commit) from 4e9506ac31705f5099f226128b98ae12a4ba9772 (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=c2ef7abe0462ff66151403a9a16b4652886d56cf commit c2ef7abe0462ff66151403a9a16b4652886d56cf Author: KWSys Robot kwro...@kitware.com AuthorDate: Sun Apr 10 00:01:07 2011 -0400 Commit: KWSys Robot kwro...@kitware.com CommitDate: Sun Apr 10 00:13:04 2011 -0400 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index f0da2fc..99ee150 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 04) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 09) +SET(KWSYS_DATE_STAMP_DAY 10) --- 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
