Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-25 23:42-0400 Bill Hoffman wrote: Either one [of the executables] should show the issue. I did show the wrong output. When it fails you get no output. I now have a much simplified file (compressed so that mailers won't mess it up, but uncompressed it expands only to 205 bytes) to search that still triggers the issue (no output from downloaded cmake while the bootstrapped version finds the string). I used emacs to cut out everything after INFO:compiler[GNU]INFO:platform[] in the file and a lot before it including many long chains of NULLS that were between non-NULL characters. The pattern of the non-NULL characters before the string appears to be important for triggering the bug. If I cut out any of them, suddenly the downloaded CMake starts working and finds INFO:compiler[GNU]INFO:platform[]. So from these experiments it appears a particular pattern of certain strings delimited by NULLs where the number of NULLs don't matter (although I didn't check by removing all NULLs whether at least one NULL is necessary between these particular strings) is required to trigger the issue. All other patterns I have tried of similar or smaller size prior to the string being searched for do not trigger the bug. Thus, I am beginning to wonder if there is some hash collision going on under Wine (only for instructions issued by the compiler used for the downloaded version) that is causing this particular short pattern of non-NULL characters delimited by NULL ones to cause a failure in the search for the string? Anyhow, I urge those who have installed Wine to play with this some more by editing the attached file with emacs to see what byte pattern triggers the bug (no output) and what patterns do not trigger the bug (output of -- [INFO:compiler[GNU]INFO:platform[]] ) for the downloaded version of CMake. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ INFO_string.dat.gz Description: compressed version of short file to be searched that still triggers the bug -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-25 23:26-0600 Clinton Stimpson wrote: Alan, you are in luck. They fixed it two days ago!! At first, I was confused because I was not able to reproduce it, then trying it against an older version of Wine showed the problem. commit 4a566ed3d6acd8a6e18eeaeb41d55d0f793029de Author: Piotr Caban pi...@codeweavers.com Date: Tue Oct 23 18:11:06 2012 +0200 msvcp90: Convert characters to unsigned char before passing them to functions operating on integers. That's awesome. More off list about how I can get access to this patch myself for 1.3.15 so I can do some further comprehensive testing with the downloaded CMake version. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator expressisons in target properties (was Re: conditionals in generator expressions)
Stephen Kelly wrote: The topics use-generator-target and target-location-configure-time don't depend on anything or each other, so I can work on merging them when development opens again. After that export-at-generate-time can be rewritten. After that I'll get the contents of use-generator-target-2 in, probably split into multiple topics so that the nightlies feedback stays managable. Then we can return to the link depends issues, followed by everything else. I thought about this a little bit and looked into the code, and I'm not sure it's a good plan. Making export() at generate time work means that the whole functionality needs to be available through cmTarget, and that means that almost all of the use-generator-target-2 branch would need to be copying instead of moving. To reduce code duplication it might be possible to use templates, but because the API would need to remain on cmTarget, there wouldn't be any compile-time guard by having the API also on cmGeneratorTarget. It might be possible to make some of the API in cmTarget private, but that would require template-friends, and I doubt the dashboard is ok with that. It also wouldn't solve the whole problem anyway as it's still accessible from cmTarget (this means that it's easier to add features similar to the LOCATION property). So, the requirement to access linking-related information makes it not worth moving to cmGeneratorTarget. So, I'm now thinking that a better solution would be to port the cmGeneratorExpression API back to cmTarget, and have run-time determination of whether to strip or process the link-related properties. The new plan would be: * Port cmGeneratorExpression API to cmTarget * Add a way to determine at runtime whether linking-related information is being requested at configure-time or generate-time. A property on the Makefile might work. * Add a const char *config where appropriate to cmTarget API to pass to the generator expressions. * Return to the depends issue and everything else. Any thoughts on that? Have I missed something? Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Generator expressisons in target properties
On 10/26/2012 06:10 AM, Stephen Kelly wrote: The new plan would be: * Port cmGeneratorExpression API to cmTarget * Add a way to determine at runtime whether linking-related information is being requested at configure-time or generate-time. A property on the Makefile might work. * Add a const char *config where appropriate to cmTarget API to pass to the generator expressions. * Return to the depends issue and everything else. Sounds good. Due to things like the LOCATION properties and export() we have long supported on-demand evaluation of things at configure time that normally should not be needed until generate time. Hence the undefined behavior of setting certain properties too late. Essentially someone needs to be able to ask at configure time What would this be if we generate now?. If we had CMake to do over again we would not allow this but it is long since too late for that. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013609]: RPM generator wrongly add parents directories to the package
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13609 == Reported By:barth Assigned To: == Project:CMake Issue ID: 13609 Category: CPack Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2012-10-26 14:55 CEST Last Modified: 2012-10-26 14:55 CEST == Summary:RPM generator wrongly add parents directories to the package Description: When an install instruction is added such as : install(FILES xxx.conf DESTINATION /etc/httpd/conf.d) then the section %files in the generated spec file contains : %dir /etc %dir /etc/httpd %dir /etc/httpd/conf.d It is wrong as the RPM must not own system directories. == Issue History Date ModifiedUsername FieldChange == 2012-10-26 14:55 barth New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Incomplete gfortran library link command sometimes mysteriously occurs with MinGW/MSYS on Wine-1.5.15 platform
On 2012-10-26 02:15-0700 Alan W. Irwin wrote: On 2012-10-25 23:26-0600 Clinton Stimpson wrote: Alan, you are in luck. They fixed it two days ago!! At first, I was confused because I was not able to reproduce it, then trying it against an older version of Wine showed the problem. commit 4a566ed3d6acd8a6e18eeaeb41d55d0f793029de Author: Piotr Caban pi...@codeweavers.com Date: Tue Oct 23 18:11:06 2012 +0200 msvcp90: Convert characters to unsigned char before passing them to functions operating on integers. That's awesome. Furthermore, I just discovered that patch got into the just-released Wine-1.5.16 so I will give that version a try for my comprehensive checks rather than attempting to carry on with a patched version of 1.5.15. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] Variable target name visible at the top level
Hi All!
I have project with the structure similar to this
worker
| |
| chatterbox
| ||
| |CMakeLists.txt
| |
| externals
| ||
| |sndlib
| | |
| | CMakeLists.txt
| CMakeLists.txt
|
CMakeLists.txt
$ cat worker/CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
add_subdirectory(externals)
add_subdirectory(chatterbox)
If I set sndlib target as a variable
set (snd_lib sndlib)
add_library(${snd_lib} SHARED ...)
variable ${snd_lib} is undefined at the parent scope, i.e. I can't use
${snd_lib} in chatterbox/ CMakeLists.txt
target_link_libraries(chatterbox ${snd_lib}) # ${snd_lib} is empty!
How to handle this situation in a proper way?
--
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] Variable target name visible at the top level
2012/10/26 Vyacheslav Karamov ubuntul...@yandex.ru:
Hi All!
I have project with the structure similar to this
worker
| |
| chatterbox
| ||
| |CMakeLists.txt
| |
| externals
| ||
| |sndlib
| | |
| | CMakeLists.txt
| CMakeLists.txt
|
CMakeLists.txt
$ cat worker/CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
add_subdirectory(externals)
add_subdirectory(chatterbox)
If I set sndlib target as a variable
set (snd_lib sndlib)
add_library(${snd_lib} SHARED ...)
variable ${snd_lib} is undefined at the parent scope, i.e. I can't use
${snd_lib} in chatterbox/ CMakeLists.txt
target_link_libraries(chatterbox ${snd_lib}) # ${snd_lib} is empty!
From your description this is strange because 'chatterbox'
is a subdir of 'worker' where snd_lib has been defined so it should be
visible, I guess...
unless you define the snd_lib var AFTER you
add_subdirectory(chatterbox)
since add_subdirectory process subdir first you must define
variable you need before add_subdirectory.
How to handle this situation in a proper way?
Define it at the scope it ought to be ?
or use
set (snd_lib sndlib PARENT_SCOPE)
but again I think your problems comes from the fact
your defined your var after add_subdirectory.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] Variable target name visible at the top level
Thank you, but if I need variable two level up?
26.10.2012 12:07, Rolf Eike Beer пишет:
On Fr., 26. Okt. 2012 10:22:51 CEST, Vyacheslav Karamov ubuntul...@yandex.ru
wrote:
Hi All!
I have project with the structure similar to this
set (snd_lib sndlib)
add_library(${snd_lib} SHARED ...)
How to handle this situation in a proper way?
set(... PARENT_SCOPE)
This will propagate the variable one level up.
Eike
--
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] Variable target name visible at the top level
2012/10/26 Vyacheslav Karamov ubuntul...@yandex.ru: Thank you, but if I need variable two level up? you may be able to use a GLOBAL property see: cmake --help-command set_property or may be a CACHE variable. but from my point of view, it looks like you have a design issue. Why would you need to jump scope like that? -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Variable target name visible at the top level
26.10.2012 12:16, Eric Noulard пишет:
2012/10/26 Vyacheslav Karamov ubuntul...@yandex.ru:
Hi All!
I have project with the structure similar to this
worker
| |
| chatterbox
| ||
| |CMakeLists.txt
| |
| externals
| ||
| |sndlib
| | |
| | CMakeLists.txt
| CMakeLists.txt
|
CMakeLists.txt
$ cat worker/CMakeLists.txt
cmake_minimum_required(VERSION 2.6)
add_subdirectory(externals)
add_subdirectory(chatterbox)
If I set sndlib target as a variable
set (snd_lib sndlib)
add_library(${snd_lib} SHARED ...)
variable ${snd_lib} is undefined at the parent scope, i.e. I can't use
${snd_lib} in chatterbox/ CMakeLists.txt
target_link_libraries(chatterbox ${snd_lib}) # ${snd_lib} is empty!
From your description this is strange because 'chatterbox'
is a subdir of 'worker' where snd_lib has been defined so it should be
visible, I guess...
unless you define the snd_lib var AFTER you
add_subdirectory(chatterbox)
since add_subdirectory process subdir first you must define
variable you need before add_subdirectory.
I have added externals before chatterbox, so
${snd_lib} should be defined in chatterbox.
How to handle this situation in a proper way?
Define it at the scope it ought to be ?
or use
set (snd_lib sndlib PARENT_SCOPE)
but again I think your problems comes from the fact
your defined your var after add_subdirectory.
PARENT_SCOPE variable is visible only in a parent scope, not in a
current one. But I need it in current scope, parent scope and scope
above parent.
--
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] GenerateExportHeader for module library
Hello, I want to create a module with two symbols exported with visual: startPlugin stopPlugin I wish I could use the convenient GENERATE_EXPORT_HEADER function to do so. Is there any reason why the GENERATE_EXPORT_HEADER function is disabled for the MODULE library type ? Thanks, Gregoire -- 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] Variable target name visible at the top level
2012/10/26 Vyacheslav Karamov ubuntul...@yandex.ru: How to handle this situation in a proper way? Define it at the scope it ought to be ? or use set (snd_lib sndlib PARENT_SCOPE) but again I think your problems comes from the fact your defined your var after add_subdirectory. PARENT_SCOPE variable is visible only in a parent scope, not in a current one. But I need it in current scope, parent scope and scope above parent. Then I guess you should try to use a global property or cached var. Some example attached. As you'll see both mechanism may achieve what you with varying bevahior. If you want to learn the differences: cmake --help-command get_property cmake --help-command set_property cmake --help-command set -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org multi-scope-var-or-props.tgz Description: GNU Zip compressed data -- 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] [PATCH] Optionally skip link dependencies on shared library files
Cool, thanks. I'll try this!
Sent from my iPhone
On Oct 26, 2012, at 8:43, Brad King brad.k...@kitware.com wrote:
Add target property LINK_DEPENDS_NO_SHARED and initialization variable
CMAKE_LINK_DEPENDS_NO_SHARED to enable this behavior.
Suggested-by: Leif Walsh leif.wa...@gmail.com
---
On 08/03/2012 04:57 PM, Leif Walsh wrote:
On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat ap...@gmx.de wrote:
Actually no, adding new public API, changing existing API in
compatible ways are things you can do with a shared library which
needs relinking.
Not without changing the header files, which forces
recompilation. As the author of a shared library, your header
files are your contract with your clients.
Great point. Please try this patch on top of 2.8.10-rc3.
Then build with -DCMAKE_LINK_DEPENDS_NO_SHARED=1 or add
set(CMAKE_LINK_DEPENDS_NO_SHARED 1)
to the top of your project.
-Brad
Source/cmComputeLinkInformation.cxx | 10 +-
Source/cmComputeLinkInformation.h |1 +
Source/cmDocumentVariables.cxx |9 +
Source/cmTarget.cxx | 17 +
4 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/Source/cmComputeLinkInformation.cxx
b/Source/cmComputeLinkInformation.cxx
index cd3ef59..d8ffb5e 100644
--- a/Source/cmComputeLinkInformation.cxx
+++ b/Source/cmComputeLinkInformation.cxx
@@ -277,6 +277,10 @@ cmComputeLinkInformation
this-UseImportLibrary =
this-Makefile-GetDefinition(CMAKE_IMPORT_LIBRARY_SUFFIX)?true:false;
+ // Check whether we should skip dependencies on shared library files.
+ this-LinkDependsNoShared =
+this-Target-GetPropertyAsBool(LINK_DEPENDS_NO_SHARED);
+
// On platforms without import libraries there may be a special flag
// to use when creating a plugin (module) that obtains symbols from
// the program that will load it.
@@ -650,7 +654,11 @@ void cmComputeLinkInformation::AddItem(std::string
const item, cmTarget* tgt)
// Pass the full path to the target file.
std::string lib = tgt-GetFullPath(config, implib, true);
- this-Depends.push_back(lib);
+ if(!this-LinkDependsNoShared ||
+ tgt-GetType() != cmTarget::SHARED_LIBRARY)
+{
+this-Depends.push_back(lib);
+}
this-AddTargetItem(lib, tgt);
this-AddLibraryRuntimeInfo(lib, tgt);
diff --git a/Source/cmComputeLinkInformation.h
b/Source/cmComputeLinkInformation.h
index f60f8d3..e0078af 100644
--- a/Source/cmComputeLinkInformation.h
+++ b/Source/cmComputeLinkInformation.h
@@ -82,6 +82,7 @@ private:
// Configuration information.
const char* Config;
const char* LinkLanguage;
+ bool LinkDependsNoShared;
// Modes for dealing with dependent shared libraries.
enum SharedDepMode
diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 8db0e8f..55d70f8 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1222,6 +1222,15 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
Variables that Control the Build);
cm-DefineProperty
+(CMAKE_LINK_DEPENDS_NO_SHARED, cmProperty::VARIABLE,
+ Whether to skip link dependencies on shared library files.,
+ This variable initializes the LINK_DEPENDS_NO_SHARED
+ property on targets when they are created.
+ See that target property for additional information.,
+ false,
+ Variables that Control the Build);
+
+ cm-DefineProperty
(CMAKE_AUTOMOC, cmProperty::VARIABLE,
Whether to handle moc automatically for Qt targets.,
This variable is used to initialize the
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 423b350..9cfcb63 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -651,6 +651,22 @@ void cmTarget::DefineProperties(cmake *cm)
custom Makefile link rules.);
cm-DefineProperty
+(LINK_DEPENDS_NO_SHARED, cmProperty::TARGET,
+ Do not depend on linked shared library files.,
+ Set this property to true to tell CMake generators not to add
+ file-level dependencies on the shared library files linked by
+ this target.
+ Modification to the shared libraries will not be sufficient to
+ re-link this target.
+ Logical target-level dependencies will not be affected so the
+ linked shared libraries will still be brought up to date before
+ this target is built.
+ \n
+ This property is initialized by the value of the variable
+ CMAKE_LINK_DEPENDS_NO_SHARED if it is set when a target is
+ created.);
+
+ cm-DefineProperty
(LINK_INTERFACE_LIBRARIES, cmProperty::TARGET,
List public interface libraries for a shared library or executable.,
By default linking to a shared library target transitively
@@ -1314,6 +1330,7 @@ void cmTarget::SetMakefile(cmMakefile* mf)
this-SetPropertyDefault(OSX_ARCHITECTURES, 0);
Re: [CMake] [PATCH] Optionally skip link dependencies on shared library files
This is exactly what I wanted, and the results were incredible. Thank
you.
I'll patch all my installs with this and hope it gets in a public release
soon.
Leif Walsh leif.wa...@gmail.com writes:
Cool, thanks. I'll try this!
Sent from my iPhone
On Oct 26, 2012, at 8:43, Brad King brad.k...@kitware.com wrote:
Add target property LINK_DEPENDS_NO_SHARED and initialization variable
CMAKE_LINK_DEPENDS_NO_SHARED to enable this behavior.
Suggested-by: Leif Walsh leif.wa...@gmail.com
---
On 08/03/2012 04:57 PM, Leif Walsh wrote:
On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat ap...@gmx.de wrote:
Actually no, adding new public API, changing existing API in
compatible ways are things you can do with a shared library which
needs relinking.
Not without changing the header files, which forces
recompilation. As the author of a shared library, your header
files are your contract with your clients.
Great point. Please try this patch on top of 2.8.10-rc3.
Then build with -DCMAKE_LINK_DEPENDS_NO_SHARED=1 or add
set(CMAKE_LINK_DEPENDS_NO_SHARED 1)
to the top of your project.
-Brad
Source/cmComputeLinkInformation.cxx | 10 +-
Source/cmComputeLinkInformation.h |1 +
Source/cmDocumentVariables.cxx |9 +
Source/cmTarget.cxx | 17 +
4 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/Source/cmComputeLinkInformation.cxx
b/Source/cmComputeLinkInformation.cxx
index cd3ef59..d8ffb5e 100644
--- a/Source/cmComputeLinkInformation.cxx
+++ b/Source/cmComputeLinkInformation.cxx
@@ -277,6 +277,10 @@ cmComputeLinkInformation
this-UseImportLibrary =
this-Makefile-GetDefinition(CMAKE_IMPORT_LIBRARY_SUFFIX)?true:false;
+ // Check whether we should skip dependencies on shared library files.
+ this-LinkDependsNoShared =
+this-Target-GetPropertyAsBool(LINK_DEPENDS_NO_SHARED);
+
// On platforms without import libraries there may be a special flag
// to use when creating a plugin (module) that obtains symbols from
// the program that will load it.
@@ -650,7 +654,11 @@ void cmComputeLinkInformation::AddItem(std::string
const item, cmTarget* tgt)
// Pass the full path to the target file.
std::string lib = tgt-GetFullPath(config, implib, true);
- this-Depends.push_back(lib);
+ if(!this-LinkDependsNoShared ||
+ tgt-GetType() != cmTarget::SHARED_LIBRARY)
+{
+this-Depends.push_back(lib);
+}
this-AddTargetItem(lib, tgt);
this-AddLibraryRuntimeInfo(lib, tgt);
diff --git a/Source/cmComputeLinkInformation.h
b/Source/cmComputeLinkInformation.h
index f60f8d3..e0078af 100644
--- a/Source/cmComputeLinkInformation.h
+++ b/Source/cmComputeLinkInformation.h
@@ -82,6 +82,7 @@ private:
// Configuration information.
const char* Config;
const char* LinkLanguage;
+ bool LinkDependsNoShared;
// Modes for dealing with dependent shared libraries.
enum SharedDepMode
diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 8db0e8f..55d70f8 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1222,6 +1222,15 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
Variables that Control the Build);
cm-DefineProperty
+(CMAKE_LINK_DEPENDS_NO_SHARED, cmProperty::VARIABLE,
+ Whether to skip link dependencies on shared library files.,
+ This variable initializes the LINK_DEPENDS_NO_SHARED
+ property on targets when they are created.
+ See that target property for additional information.,
+ false,
+ Variables that Control the Build);
+
+ cm-DefineProperty
(CMAKE_AUTOMOC, cmProperty::VARIABLE,
Whether to handle moc automatically for Qt targets.,
This variable is used to initialize the
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 423b350..9cfcb63 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -651,6 +651,22 @@ void cmTarget::DefineProperties(cmake *cm)
custom Makefile link rules.);
cm-DefineProperty
+(LINK_DEPENDS_NO_SHARED, cmProperty::TARGET,
+ Do not depend on linked shared library files.,
+ Set this property to true to tell CMake generators not to add
+ file-level dependencies on the shared library files linked by
+ this target.
+ Modification to the shared libraries will not be sufficient to
+ re-link this target.
+ Logical target-level dependencies will not be affected so the
+ linked shared libraries will still be brought up to date before
+ this target is built.
+ \n
+ This property is initialized by the value of the variable
+ CMAKE_LINK_DEPENDS_NO_SHARED if it is set when a target is
+ created.);
+
+ cm-DefineProperty
(LINK_INTERFACE_LIBRARIES, cmProperty::TARGET,
List public interface libraries for a shared library or executable.,
By
Re: [CMake] [PATCH] Optionally skip link dependencies on shared library files
On 10/26/2012 09:43 AM, Leif Walsh wrote: This is exactly what I wanted, and the results were incredible. Thanks for testing. I've merged it to our 'next' branch in Git: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed976313 We still need to add a test before it can be merged for inclusion. It should be in 2.8.11. -Brad -- 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] [PATCH] Optionally skip link dependencies on shared library files
On 10/26/2012 9:43 AM, Leif Walsh wrote: This is exactly what I wanted, and the results were incredible. Thank you. If you want to thank us... Please help out and create a test for this so we can put it in the next release. The test should build a shared library and link it to an exe, modify the shared library .c, rebuild and verify the .exe is still older than the .so or .dll. It would be great if you could take the time to create a test for this. Thanks. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] [PATCH] Optionally skip link dependencies on shared library files
Sure thing. Can you let me know where to find an example test? I'll pattern match one over the weekend. Sent from my iPhone On Oct 26, 2012, at 10:38, Bill Hoffman bill.hoff...@kitware.com wrote: On 10/26/2012 9:43 AM, Leif Walsh wrote: This is exactly what I wanted, and the results were incredible. Thank you. If you want to thank us... Please help out and create a test for this so we can put it in the next release. The test should build a shared library and link it to an exe, modify the shared library .c, rebuild and verify the .exe is still older than the .so or .dll. It would be great if you could take the time to create a test for this. Thanks. -Bill -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 -- 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] [PATCH] Optionally skip link dependencies on shared library files
On 10/26/2012 10:39 AM, Leif Walsh wrote:
Sure thing. Can you let me know where to find an example test? I'll pattern
match one over the weekend.
Most CMake tests just verify that binaries build correctly.
The Tests/BuildDepends test is the only one that actually
tests rebuild behavior. It has custom commands to build a
sub-project in its Project subdirectory multiple times while
making modifications in between.
You'll have to modify the inner test project to add a shared
library and an executable that links to it. Set the new
property on the executable only. After the first build,
verify that the executable's time is newer than the library
time. Between builds, modify a the shared library source
(which of course will have to be in the build tree to avoid
modifying CMake's source tree). After the second build
verify that the library is newer than the executable.
Checking the file times is probably most easily done as a
custom target on the inner project that depends on the
executable. Its COMMAND should run a cmake script and
pass -Dexe=$TARGET_FILE:exe -Dlib=$TARGET_FILE:lib to
it. The script can compare the ${lib} and ${exe} file
times with if(... FILE_IS_NEWER ...).
Thanks,
-Brad
--
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] [PATCH] Optionally skip link dependencies on shared library files
Sounds good, I'll send a patch soon.
Sent from my iPhone
On Oct 26, 2012, at 11:13, Brad King brad.k...@kitware.com wrote:
On 10/26/2012 10:39 AM, Leif Walsh wrote:
Sure thing. Can you let me know where to find an example test? I'll pattern
match one over the weekend.
Most CMake tests just verify that binaries build correctly.
The Tests/BuildDepends test is the only one that actually
tests rebuild behavior. It has custom commands to build a
sub-project in its Project subdirectory multiple times while
making modifications in between.
You'll have to modify the inner test project to add a shared
library and an executable that links to it. Set the new
property on the executable only. After the first build,
verify that the executable's time is newer than the library
time. Between builds, modify a the shared library source
(which of course will have to be in the build tree to avoid
modifying CMake's source tree). After the second build
verify that the library is newer than the executable.
Checking the file times is probably most easily done as a
custom target on the inner project that depends on the
executable. Its COMMAND should run a cmake script and
pass -Dexe=$TARGET_FILE:exe -Dlib=$TARGET_FILE:lib to
it. The script can compare the ${lib} and ${exe} file
times with if(... FILE_IS_NEWER ...).
Thanks,
-Brad
--
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] [PATCH] Optionally skip link dependencies on shared library files
On Fri, Oct 26, 2012 at 11:22 AM, Leif Walsh leif.wa...@gmail.com wrote:
Sounds good, I'll send a patch soon.
Sent from my iPhone
On Oct 26, 2012, at 11:13, Brad King brad.k...@kitware.com wrote:
On 10/26/2012 10:39 AM, Leif Walsh wrote:
Sure thing. Can you let me know where to find an example test? I'll pattern
match one over the weekend.
Most CMake tests just verify that binaries build correctly.
The Tests/BuildDepends test is the only one that actually
tests rebuild behavior. It has custom commands to build a
sub-project in its Project subdirectory multiple times while
making modifications in between.
You'll have to modify the inner test project to add a shared
library and an executable that links to it. Set the new
property on the executable only. After the first build,
verify that the executable's time is newer than the library
time. Between builds, modify a the shared library source
(which of course will have to be in the build tree to avoid
modifying CMake's source tree). After the second build
verify that the library is newer than the executable.
Checking the file times is probably most easily done as a
custom target on the inner project that depends on the
executable. Its COMMAND should run a cmake script and
pass -Dexe=$TARGET_FILE:exe -Dlib=$TARGET_FILE:lib to
it. The script can compare the ${lib} and ${exe} file
times with if(... FILE_IS_NEWER ...).
Thanks,
-Brad
--
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
Please send patches as produced by git format-patch -1
Thx,
David
--
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] GenerateExportHeader for module library
Gregoire Aujay wrote: Hello, I want to create a module with two symbols exported with visual: startPlugin stopPlugin I wish I could use the convenient GENERATE_EXPORT_HEADER function to do so. Is there any reason why the GENERATE_EXPORT_HEADER function is disabled for the MODULE library type ? When I wrote GenerateExportHeader, I didn't know of any reason to link to a MODULE. I thought MODULEs were always plugins to be loaded at runtime? What does 'two symbols exported with visual' mean? Thanks, Steve. -- 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] GenerateExportHeader for module library
Hello,
I am doing my tests with visual 2008 and mingw.
As far as I understand a module is like a shared library that cannot be linked.
Instead it is dynamically loaded and then we find and use symbols in it. It is
like doing the linker's job manually at runtime.
If nothing is exported from my module then I do cannot find any symbol in it.
Or at least I do not know how to do so.
I modified the GenerateExportHeader module to be able to export symbols from my
MODULE:
# if(${type} STREQUAL MODULE)
# message(WARNING This macro should not be used with libraries of type
MODULE)
# return()
# endif()
if(NOT ${type} STREQUAL STATIC_LIBRARY AND NOT ${type} STREQUAL
SHARED_LIBRARY AND NOT ${type} STREQUAL MODULE_LIBRARY)
message(WARNING This macro can only be used with libraries)
return()
endif()
Regards,
Gregoire
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Stephen Kelly
Sent: vendredi 26 octobre 2012 17:45
To: cmake@cmake.org
Subject: Re: [CMake] GenerateExportHeader for module library
Gregoire Aujay wrote:
Hello,
I want to create a module with two symbols exported with visual:
startPlugin
stopPlugin
I wish I could use the convenient GENERATE_EXPORT_HEADER function to
do so. Is there any reason why the GENERATE_EXPORT_HEADER function is
disabled for the MODULE library type ?
When I wrote GenerateExportHeader, I didn't know of any reason to link to a
MODULE. I thought MODULEs were always plugins to be loaded at runtime?
What does 'two symbols exported with visual' mean?
Thanks,
Steve.
--
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
[CMake] CPack issue with long path names being misplaced in TGZ file
Hi all, I'm having an issue to use CPack with big file paths. I have cmake-2.8.9. I built a very simple testcase to show this issue. These are the files in the project: ./CMakeLists.txt ./control/examples/path-with-very-long-length/some_file2.txt ./control/examples/path-with-very-long-length/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big/ok-that-is-enough.txt ./control/examples/some_file.txt All files are empty, unless for the CMakeLists.txt, of course. It has the following: - cmake_minimum_required(VERSION 2.8) project (bugtest) install(DIRECTORY control/ DESTINATION control) include (InstallRequiredSystemLibraries) include (CPack) - As a simple way to create the other empty files, we can use the following commands: mkdir -p control/examples/path-with-very-long-length/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big touch control/examples/some_file.txt touch control/examples/path-with-very-long-length/some_file2.txt touch control/examples/path-with-very-long-length/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big/ok-that-is-enough.txt The 2 files with smaller paths goes to the expected locations under tar_root/bugtest-0.1.1/ but the file with the bigger path gets part of the path stripped and loose the initial bugtest-0.1.1 directory, going to: tar_root/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big/ok-that-is-enough.txt I'm building and packaging it with the commands: cmake ../bugtest cpack -C CPackConfig.cmake -G TGZ Can someone help me to find out if it is a bug or how to fix it? Thanks for any help, Marcus -- 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] CPack issue with long path names being misplaced in TGZ file
I'm VERY sorry to bug you guys! I just realized that this is an issue with the midnight commander. It is not reading inside tarballs correctly. But CPack is creating the tarball correctly. Sorry again, Marcus On Fri, Oct 26, 2012 at 7:59 PM, Marcus Bartholomeu cm...@tecativa.com.brwrote: Hi all, I'm having an issue to use CPack with big file paths. I have cmake-2.8.9. I built a very simple testcase to show this issue. These are the files in the project: ./CMakeLists.txt ./control/examples/path-with-very-long-length/some_file2.txt ./control/examples/path-with-very-long-length/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big/ok-that-is-enough.txt ./control/examples/some_file.txt All files are empty, unless for the CMakeLists.txt, of course. It has the following: - cmake_minimum_required(VERSION 2.8) project (bugtest) install(DIRECTORY control/ DESTINATION control) include (InstallRequiredSystemLibraries) include (CPack) - As a simple way to create the other empty files, we can use the following commands: mkdir -p control/examples/path-with-very-long-length/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big touch control/examples/some_file.txt touch control/examples/path-with-very-long-length/some_file2.txt touch control/examples/path-with-very-long-length/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big/ok-that-is-enough.txt The 2 files with smaller paths goes to the expected locations under tar_root/bugtest-0.1.1/ but the file with the bigger path gets part of the path stripped and loose the initial bugtest-0.1.1 directory, going to: tar_root/to-test-if-it-breaks-the-cpack/a-little-bit-more-characters-to-make-it-big/ok-that-is-enough.txt I'm building and packaging it with the commands: cmake ../bugtest cpack -C CPackConfig.cmake -G TGZ Can someone help me to find out if it is a bug or how to fix it? Thanks for any help, Marcus -- 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] CPack issue with long path names being misplaced in TGZ file
2012/10/27 Marcus Bartholomeu cm...@tecativa.com.br: I'm VERY sorry to bug you guys! I just realized that this is an issue with the midnight commander. It is not reading inside tarballs correctly. But CPack is creating the tarball correctly. Sorry again, Don't be, those bugs that are solving themselves after some time are my favourite ones :-] -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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.9-1214-g3c84971
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 3c849715b594ef736dd0ae0e31106d52da10bbb3 (commit)
via ed9763136acdb8594e4b85ab7b2e4e2828d8b775 (commit)
via 259cff94ff81f7b95b7375905fe0e0a292f70dda (commit)
from ed8aca6e5363fd9c5a3a486673d37fd6f51db09a (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=3c849715b594ef736dd0ae0e31106d52da10bbb3
commit 3c849715b594ef736dd0ae0e31106d52da10bbb3
Merge: ed8aca6 ed97631
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Oct 26 10:31:19 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Oct 26 10:31:19 2012 -0400
Merge topic 'link-depends-no-shared' into next
ed97631 Optionally skip link dependencies on shared library files
259cff9 CMake Nightly Date Stamp
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ed9763136acdb8594e4b85ab7b2e4e2828d8b775
commit ed9763136acdb8594e4b85ab7b2e4e2828d8b775
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Oct 26 08:25:36 2012 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Oct 26 08:28:16 2012 -0400
Optionally skip link dependencies on shared library files
Add target property LINK_DEPENDS_NO_SHARED and initialization variable
CMAKE_LINK_DEPENDS_NO_SHARED to enable this behavior.
Suggested-by: Leif Walsh leif.wa...@gmail.com
diff --git a/Source/cmComputeLinkInformation.cxx
b/Source/cmComputeLinkInformation.cxx
index cd3ef59..d8ffb5e 100644
--- a/Source/cmComputeLinkInformation.cxx
+++ b/Source/cmComputeLinkInformation.cxx
@@ -277,6 +277,10 @@ cmComputeLinkInformation
this-UseImportLibrary =
this-Makefile-GetDefinition(CMAKE_IMPORT_LIBRARY_SUFFIX)?true:false;
+ // Check whether we should skip dependencies on shared library files.
+ this-LinkDependsNoShared =
+this-Target-GetPropertyAsBool(LINK_DEPENDS_NO_SHARED);
+
// On platforms without import libraries there may be a special flag
// to use when creating a plugin (module) that obtains symbols from
// the program that will load it.
@@ -650,7 +654,11 @@ void cmComputeLinkInformation::AddItem(std::string const
item, cmTarget* tgt)
// Pass the full path to the target file.
std::string lib = tgt-GetFullPath(config, implib, true);
- this-Depends.push_back(lib);
+ if(!this-LinkDependsNoShared ||
+ tgt-GetType() != cmTarget::SHARED_LIBRARY)
+{
+this-Depends.push_back(lib);
+}
this-AddTargetItem(lib, tgt);
this-AddLibraryRuntimeInfo(lib, tgt);
diff --git a/Source/cmComputeLinkInformation.h
b/Source/cmComputeLinkInformation.h
index f60f8d3..e0078af 100644
--- a/Source/cmComputeLinkInformation.h
+++ b/Source/cmComputeLinkInformation.h
@@ -82,6 +82,7 @@ private:
// Configuration information.
const char* Config;
const char* LinkLanguage;
+ bool LinkDependsNoShared;
// Modes for dealing with dependent shared libraries.
enum SharedDepMode
diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx
index 8db0e8f..55d70f8 100644
--- a/Source/cmDocumentVariables.cxx
+++ b/Source/cmDocumentVariables.cxx
@@ -1222,6 +1222,15 @@ void cmDocumentVariables::DefineVariables(cmake* cm)
Variables that Control the Build);
cm-DefineProperty
+(CMAKE_LINK_DEPENDS_NO_SHARED, cmProperty::VARIABLE,
+ Whether to skip link dependencies on shared library files.,
+ This variable initializes the LINK_DEPENDS_NO_SHARED
+ property on targets when they are created.
+ See that target property for additional information.,
+ false,
+ Variables that Control the Build);
+
+ cm-DefineProperty
(CMAKE_AUTOMOC, cmProperty::VARIABLE,
Whether to handle moc automatically for Qt targets.,
This variable is used to initialize the
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 423b350..9cfcb63 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -651,6 +651,22 @@ void cmTarget::DefineProperties(cmake *cm)
custom Makefile link rules.);
cm-DefineProperty
+(LINK_DEPENDS_NO_SHARED, cmProperty::TARGET,
+ Do not depend on linked shared library files.,
+ Set this property to true to tell CMake generators not to add
+ file-level dependencies on the shared library files linked by
+ this target.
+ Modification to the shared libraries will not be sufficient to
+ re-link this target.
+ Logical target-level dependencies will not be affected so the
+ linked shared libraries will still be brought up to date before
+ this target is built.
+ \n
+
[Cmake-commits] CMake branch, next, updated. v2.8.9-1217-g403da25
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 403da25e38c24a2631425d79f6c74498f56bcabd (commit)
via 035e7bd04ea620c813adcdf402de2c25b6ce7e9c (commit)
via c65a2ea6a83f274afc52ca6adc457dec069de064 (commit)
from 3c849715b594ef736dd0ae0e31106d52da10bbb3 (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=403da25e38c24a2631425d79f6c74498f56bcabd
commit 403da25e38c24a2631425d79f6c74498f56bcabd
Merge: 3c84971 035e7bd
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Oct 26 12:48:08 2012 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Oct 26 12:48:08 2012 -0400
Merge topic 'vs10-DelaySign-KeyFile' into next
035e7bd VS10: Honor /DELAYSIGN and /KEYFILE flags (#13601)
c65a2ea VS10: Refactor link options collection
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=035e7bd04ea620c813adcdf402de2c25b6ce7e9c
commit 035e7bd04ea620c813adcdf402de2c25b6ce7e9c
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Oct 26 11:02:42 2012 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Oct 26 11:02:42 2012 -0400
VS10: Honor /DELAYSIGN and /KEYFILE flags (#13601)
Fix the VS 10 link flag map to name the project file entries correctly.
The VS 11 link flag map already has the correct names. Generate the
entries in the PropertyGroup along with incremental linking options.
Drop them from the Link element because VS does not use them.
diff --git a/Source/cmVS10LinkFlagTable.h b/Source/cmVS10LinkFlagTable.h
index c60e8eb..64febbb 100644
--- a/Source/cmVS10LinkFlagTable.h
+++ b/Source/cmVS10LinkFlagTable.h
@@ -182,8 +182,8 @@ static cmVS7FlagTable cmVS10LinkFlagTable[] =
{SupportUnloadOfDelayLoadedDLL, DELAY:UNLOAD, , true, 0},
{SupportNobindOfDelayLoadedDLL, DELAY:NOBIND, , true, 0},
{Profile, PROFILE, , true, 0},
- {DelaySign, DELAYSIGN:NO, , false, 0},
- {DelaySign, DELAYSIGN, , true, 0},
+ {LinkDelaySign, DELAYSIGN:NO, , false, 0},
+ {LinkDelaySign, DELAYSIGN, , true, 0},
{CLRUnmanagedCodeCheck, CLRUNMANAGEDCODECHECK:NO, , false, 0},
{CLRUnmanagedCodeCheck, CLRUNMANAGEDCODECHECK, , true, 0},
{ImageHasSafeExceptionHandlers, SAFESEH:NO, , false, 0},
@@ -294,7 +294,7 @@ static cmVS7FlagTable cmVS10LinkFlagTable[] =
{MergeSections, MERGE:,
Merge Sections,
, cmVS7FlagTable::UserValue},
- {KeyFile, KEYFILE:,
+ {LinkKeyFile, KEYFILE:,
Key File,
, cmVS7FlagTable::UserValue},
{KeyContainer, KEYCONTAINER:,
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index db03163..def4133 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -1106,6 +1106,23 @@ OutputLinkIncremental(std::string const configName)
*this-BuildFileStream (manifest?manifest:true)
/GenerateManifest\n;
linkOptions.RemoveFlag(GenerateManifest);
+
+ // Some link options belong here. Use them now and remove them so that
+ // WriteLinkOptions does not use them.
+ const char* flags[] = {
+LinkDelaySign,
+LinkKeyFile,
+0};
+ for(const char** f = flags; *f; ++f)
+{
+const char* flag = *f;
+if(const char* value = linkOptions.GetFlag(flag))
+ {
+ this-WritePlatformConfigTag(flag, configName.c_str(), 3);
+ *this-BuildFileStream value / flag \n;
+ linkOptions.RemoveFlag(flag);
+ }
+}
}
//
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c65a2ea6a83f274afc52ca6adc457dec069de064
commit c65a2ea6a83f274afc52ca6adc457dec069de064
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Oct 26 10:16:45 2012 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Oct 26 10:16:45 2012 -0400
VS10: Refactor link options collection
Avoid collecting the link options twice. Collect them once in a
LinkOptions member and use it from both places. We already do this for
compiler options with the ClOptions member.
diff --git a/Source/cmIDEOptions.cxx b/Source/cmIDEOptions.cxx
index d9c0e87..76a60cf 100644
--- a/Source/cmIDEOptions.cxx
+++ b/Source/cmIDEOptions.cxx
@@ -177,3 +177,14 @@ void cmIDEOptions::RemoveFlag(const char* flag)
{
this-FlagMap.erase(flag);
}
+
+//
+const char* cmIDEOptions::GetFlag(const char* flag)
+{
+ std::mapcmStdString, cmStdString::iterator i = this-FlagMap.find(flag);
+ if(i != this-FlagMap.end())
+{
+return
