[cmake-developers] [CMake 0011332]: No dependency from ADD_CUSTOM_COMMAND to external project
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11332
==
Reported By:Rolf Eike Beer
Assigned To:
==
Project:CMake
Issue ID: 11332
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2010-10-19 06:55 EDT
Last Modified: 2010-10-19 06:55 EDT
==
Summary:No dependency from ADD_CUSTOM_COMMAND to external
project
Description:
The idea is like this: we have an project that generates a couple of
files. In a special configuration of another project we need those files
as input for a special build step. Those step will take those files,
mangle them and will generate a source file at the end. I simulate this by
a simple copy below. This is then added as usual to a library (in my
example below to a executable, but that doesn't matter). When I run the
example below I get:
[ 80%] Built target Subdir_Build
make[2]: *** No rule to make target `Subdir_Build', needed by `main.c'.
Stop.
The project Subdir_Build indeed exists, as make Subdir_Build runs
fine. And it looks for me as it is properly build before the target
depending on it. I have found no way to set a dependency on the external
project (tried ADD_CUSTOM_COMMAND(DEPENDS), ADD_DEPENDENCIES, and
SET_SOURCE_FILES_PROPERTIES). If CMake can't do this it should give at
least an error at CMake time.
Put this into CMakeLists.txt
=== snip ===
PROJECT(MaindirThing C)
CMAKE_MINIMUM_REQUIRED(VERSION 2.8.2)
INCLUDE(ExternalProject)
ExternalProject_Add(Subdir_Build
PREFIX ${CMAKE_CURRENT_BINARY_DIR}/build_subdir
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/subdir
CMAKE_ARGS
-DCMAKE_INSTALL_PREFIX=${CMAKE_CURRENT_BINARY_DIR}/build_subdir/install
INSTALL_DIR
${CMAKE_CURRENT_BINARY_DIR}/build_subdir/install
)
ADD_CUSTOM_COMMAND(
OUTPUT main.c
COMMAND ${CMAKE_COMMAND}
ARGS -E copy ${CMAKE_CURRENT_BINARY_DIR}/build_subdir/install/foo
${CMAKE_CURRENT_BINARY_DIR}/main.c
DEPENDS Subdir_Build
)
ADD_EXECUTABLE(simple_exe main.c)
=== snap ===
And this goes to subdir/CMakeLists.txt
=== snip ===
PROJECT(SubdirThing NONE)
CMAKE_MINIMUM_REQUIRED(VERSION 2.6)
FILE(WRITE ${CMAKE_CURRENT_BINARY_DIR}/foo_file int main(void)\n{\n
return 0;\n}\n)
INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/foo_file DESTINATION .)
=== snap ===
==
Issue History
Date ModifiedUsername FieldChange
==
2010-10-19 06:55 Rolf Eike Beer New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011333]: FindThreads incorrectly adds -pthread to linker options
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11333 == Reported By:Rolf Eike Beer Assigned To: == Project:CMake Issue ID: 11333 Category: CMake Reproducibility:always Severity: tweak Priority: normal Status: new == Date Submitted: 2010-10-19 07:13 EDT Last Modified: 2010-10-19 07:13 EDT == Summary:FindThreads incorrectly adds -pthread to linker options Description: FindThreads sets CMAKE_THREAD_LIBS_INIT to -pthread on QNX which leads to this linker warning: c++: unrecognized option '-pthread' QNX has the phtread stuff in the standard library. The best way would IMHO be to check if a program that uses pthread_* can be successfully linked without specifying any linker option before trying out the different flags. == Issue History Date ModifiedUsername FieldChange == 2010-10-19 07:13 Rolf Eike Beer New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake platform support for TI C6000 and TMS470 (OMAP)
Alex, For the assembler support I note that if I put ENABLE_LANGUAGE() in the tool chain file CMake locks up, this also happens if I put it in my Platform/Generic-cl6x.cmake, I have had to put it in either top level CMakeLists.txt or a normal include file included from it. It would make more sense to be in the compiler file or toolchain file, I haven't looked into this further. Why would you want to put enable_language() into these files ? It is not intended to be put there. My end users just want to include support for a specific TI compiler, and neither no nor care that they have to do something special to enable assembler support along with compilation (they wouldn't expect this). Therefore that is why I thought it would be cleaner to do it this way, by them just specifying a tool chain file and not having to change their local CMakelists.txt. The TI tools are available on both Linux and Windows (I use both). I Are there versions which can be downloaded for free, evaluation versions or something ? Do you have a link ? For the forward/backslash problem the same situation also arises for the compiler and linker. It appears that if the tool is invoked in Windows with an absolute filename (with forward slashes) and it is *not* in the environments PATH then it attempts to locate the other tools it needs for the different compilation pass by looking at its $0 argument, and they obviously assume backslashes at this point hence it silently fails to discover/run these other tools. Currently the only workaround is to add the compiler to the environment PATH, which isn't nice as this info is duplicated in the tool chain discovery. The alternative is to persuade CMake to either cache the path with backslashes or provide another method of changing this before compiler invocation. I haven't yet had a chance to look at the source code for this. A free Windows install is not available. -TrevK ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Fri, Oct 15, 2010 at 1:59 PM, David Cole david.c...@kitware.com wrote: On Fri, Oct 15, 2010 at 1:36 PM, David Cole david.c...@kitware.com wrote: On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/14/2010 2:18 PM, David Cole wrote: On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf neund...@kde.org mailto:neund...@kde.org wrote: On Wednesday 13 October 2010, Alexander Neundorf wrote: On Wednesday 13 October 2010, Bill Hoffman wrote: So, I think we have to use the new name approach. Do we want to call it 2? Or should we call it something else? Alex, do you have time to do this? I think it's not a good solution, and the one with CURRENT_LIST_DIR is definitely better and already implemented. And I am still convinced that I am right here, see my other mails. So I would suggest to merge the CURRENT_LIST_DIR branch for 2.8.3, and as soon as 2.8.3 is released, remove the full paths again and enable the new CMP0017 instead (prefer CMAKE_ROOT when include()d from CMAKE_ROOT) and then see what happens during the whole 2.8.4 cycle. I think this (CMP0017) is necessary, because otherwise we can only hope nothing breaks with future releases (independent from FPHSA). Alex ___ cmake-developers mailing list cmake-develop...@cmake.org mailto:cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I'm ok with this since Alex feels so strongly about it, and the code change is restricted to using CMAKE_CURRENT_LIST_DIR only when including FPHSA.cmake... (i.e. -- it should not affect including *other* files from inside of modules that are presently overridden... which was my concern -- that we'd break some *other* scenario -- since that's not true, I retract my objection.) To review the change yourself: git fetch stage gitk remotes/stage/AddCMAKE_CURRENT_LIST_DIR Look at the top 3 commits. Looks pretty safe. I'd say we should merge it to 'next' and then after a night on the dashboards, merge it to 'master' and do an rc3 release based on that. OK, lets try this one. Lets move it to next. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I'm trying to merge this, and getting conflicts when merging to 'next' because of changes in cmMakefile.cxx like this: this-AddDefinition(CMAKE_CURRENT_LIST_FILE, filenametoread); HEAD this-MarkVariableAsUsed(CMAKE_CURRENT_LIST_FILE); === this-AddDefinition(CMAKE_CURRENT_LIST_DIR, cmSystemTools::GetFilenamePath(filenametoread).c_str()); AddCMAKE_CURRENT_LIST_DIR What's the best way to resolve this conflict? Should I delete the MarkVariableAsUsed lines because they're part of the dev/strict-mode branch which is *not* going into 2.8.3? If I leave the MarkVariableAsUsed call in there, does if affect how the commit will merge to 'master'...? Arg. Never mind. I think I resolved this correctly for next (including *both* features) and pushed it just now. The conflict should not occur when merging to master, so there should be nothing to resolve when I merge to master, and the additional lines I added as conflict resolution should not end up in master. (I'm going to verify that locally right now... :-) Thanks, David Just to confirm that the current next fixes the issues I observed with CMake failing to configure Avogadro. I think your merge should be fine for master for the reason you state. Marcus ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] User vs CMake include mismatch handling
On Tue, Oct 19, 2010 at 9:46 AM, Marcus D. Hanwell marcus.hanw...@kitware.com wrote: On Fri, Oct 15, 2010 at 1:59 PM, David Cole david.c...@kitware.com wrote: On Fri, Oct 15, 2010 at 1:36 PM, David Cole david.c...@kitware.com wrote: On Fri, Oct 15, 2010 at 8:23 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/14/2010 2:18 PM, David Cole wrote: On Thu, Oct 14, 2010 at 1:30 PM, Alexander Neundorf neund...@kde.org mailto:neund...@kde.org wrote: On Wednesday 13 October 2010, Alexander Neundorf wrote: On Wednesday 13 October 2010, Bill Hoffman wrote: So, I think we have to use the new name approach. Do we want to call it 2? Or should we call it something else? Alex, do you have time to do this? I think it's not a good solution, and the one with CURRENT_LIST_DIR is definitely better and already implemented. And I am still convinced that I am right here, see my other mails. So I would suggest to merge the CURRENT_LIST_DIR branch for 2.8.3, and as soon as 2.8.3 is released, remove the full paths again and enable the new CMP0017 instead (prefer CMAKE_ROOT when include()d from CMAKE_ROOT) and then see what happens during the whole 2.8.4 cycle. I think this (CMP0017) is necessary, because otherwise we can only hope nothing breaks with future releases (independent from FPHSA). Alex ___ cmake-developers mailing list cmake-developers@cmake.org mailto:cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I'm ok with this since Alex feels so strongly about it, and the code change is restricted to using CMAKE_CURRENT_LIST_DIR only when including FPHSA.cmake... (i.e. -- it should not affect including *other* files from inside of modules that are presently overridden... which was my concern -- that we'd break some *other* scenario -- since that's not true, I retract my objection.) To review the change yourself: git fetch stage gitk remotes/stage/AddCMAKE_CURRENT_LIST_DIR Look at the top 3 commits. Looks pretty safe. I'd say we should merge it to 'next' and then after a night on the dashboards, merge it to 'master' and do an rc3 release based on that. OK, lets try this one. Lets move it to next. -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers I'm trying to merge this, and getting conflicts when merging to 'next' because of changes in cmMakefile.cxx like this: this-AddDefinition(CMAKE_CURRENT_LIST_FILE, filenametoread); HEAD this-MarkVariableAsUsed(CMAKE_CURRENT_LIST_FILE); === this-AddDefinition(CMAKE_CURRENT_LIST_DIR, cmSystemTools::GetFilenamePath(filenametoread).c_str()); AddCMAKE_CURRENT_LIST_DIR What's the best way to resolve this conflict? Should I delete the MarkVariableAsUsed lines because they're part of the dev/strict-mode branch which is *not* going into 2.8.3? If I leave the MarkVariableAsUsed call in there, does if affect how the commit will merge to 'master'...? Arg. Never mind. I think I resolved this correctly for next (including *both* features) and pushed it just now. The conflict should not occur when merging to master, so there should be nothing to resolve when I merge to master, and the additional lines I added as conflict resolution should not end up in master. (I'm going to verify that locally right now... :-) Thanks, David Just to confirm that the current next fixes the issues I observed with CMake failing to configure Avogadro. I think your merge should be fine for master for the reason you state. Marcus Thanks, Marcus. We can all use a git double-check these days... :-) ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011338]: CMake adds CURRENT_SOURCE_DIR to include_directories if there is a VTK project.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11338 == Reported By:K. R. Walker Assigned To: == Project:CMake Issue ID: 11338 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2010-10-19 18:13 EDT Last Modified: 2010-10-19 18:13 EDT == Summary:CMake adds CURRENT_SOURCE_DIR to include_directories if there is a VTK project. Description: CMake adds CMAKE_CURRENT_SOURCE_DIR to the list of include directories if a project named VTK is added to a CMake solution. cmLocalGenerator.cxx checks for the presence of VTK_SOURCE_DIR (which will be found in the cache if VTK or a project named VTK is part of the solution anywhere). If it's there, then it also looks for VTK_MAJOR_VERSION and VTK_MINOR_VERSION. If those aren't found (as they would not be in a parent scope of VTK, or a project that isn't actually building VTK), then the backwards compatibility hack is triggered and includeSourceDir is set to true. Our current workaround is to change the VTK CMake to FORCE VTK_MAJOR_VERSION and VTK_MINOR_VERSION into the cache to prevent the hack from being encountered. == Issue History Date ModifiedUsername FieldChange == 2010-10-19 18:13 K. R. Walker New Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
