|
Why, if I make a small change to my shared library, does cmake relink all of my tests to it? It's a shared library, isn't the point that it doesn't need relinking? Seems like a big waste of time. Can I suppress this in any way?
Sent from my iPhone -- 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 |
|
If you are using the Makefile system, then the libraries are newer than
your tests, so your tests seems to need an update. And sometimes programs need relinking, where should the build system now, if you really need the relinking? Am 20.07.2012 14:08, schrieb Leif Walsh: > Why, if I make a small change to my shared library, does cmake relink all of my tests to it? It's a shared library, isn't the point that it doesn't need relinking? Seems like a big waste of time. Can I suppress this in any way? > > Sent from my iPhone > -- > > 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 |
|
On Friday 20 July 2012, Andreas Naumann wrote: > If you are using the Makefile system, then the libraries are newer than > your tests, so your tests seems to need an update. > > And sometimes programs need relinking, where should the build system > now, if you really need the relinking? Yes, e.g. to make sure the library still has the necessary symbols. Alex -- 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 |
|
In reply to this post by Andreas Naumann
This is sort of the point of shared libs though, you can update them without relinking everything on your system, unless you're doing something really brain-damaged.
Is there any way I, as someone who knows my libraries are sane, can prevent this extra work and just resort to a "make clean" if I really screw something up? Sent from my iPhone On Jul 20, 2012, at 8:28, Andreas Naumann <[hidden email]> wrote: > If you are using the Makefile system, then the libraries are newer than your tests, so your tests seems to need an update. > > And sometimes programs need relinking, where should the build system now, if you really need the relinking? > > > Am 20.07.2012 14:08, schrieb Leif Walsh: >> Why, if I make a small change to my shared library, does cmake relink all of my tests to it? It's a shared library, isn't the point that it doesn't need relinking? Seems like a big waste of time. Can I suppress this in any way? >> >> Sent from my iPhone >> -- >> >> 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 |
|
Hi,
On Fri, Aug 3, 2012 at 8:41 PM, Leif Walsh <[hidden email]> wrote: > This is sort of the point of shared libs though, you can update them without relinking everything on your system, unless you're doing something really brain-damaged. Actually no, adding new public API, changing existing API in compatible ways are things you can do with a shared library which needs relinking. Changing the implementation is just one of the things you can do. The point is simply, there's no way for the buildsystem to find that out and no cmake does not provide ways to disable dependency tracking, if you want that simply don't use a buildsystem with dependency tracking - for example a shell script. Andreas -- 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 |
|
On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat <[hidden email]> 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. If you change the library in such a way that requires relinking, it's your responsibility to update the contract. Everyone in the world does this and it works just fine. My point is that, unless you are deliberately trying to be really sneaky, there's pretty much no way you can introduce a change that requires relinking but not recompiling of binaries. I am not being sneaky so this is a gigantic waste of my time. > Changing the implementation is just one of the things > you can do. The point is simply, there's no way for the buildsystem to > find that out and no cmake does not provide ways to disable dependency > tracking, if you want that simply don't use a buildsystem with > dependency tracking - for example a shell script. The build system could make the reasonable assumption that a binary does not need to be relinked with a changed shared library, if that's the only thing that's changed, or this assumption could be turned on as a feature, maybe with a policy. Most other build systems have this assumption. Tracking dependencies through header files is a much smarter way to do it, and cmake already professes to do this. If cmake cannot turn off this misfeature, it needs to. -- Cheers, Leif -- 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 |
|
I agree with Leif Walsh....
I am currently looking at replacing my unix makefile (linux+gmake, solaris+make/gmake) and Windows VS projects, with cmake. For the makefiles I get gcc to output dependency files based on header file usage, using gcc options -MM -MF -MP -MT. This has worked really well for over a year. If I modify a cpp file that is used by the shared lib, then the executable does not re-link. If I modify a .h file that is used by the shared lib *and* the executable, then it WILL re-link. Can I confirm that I cannot replicate this functionality with cmake ? If so then this may be a blocker for CMAKE adoption , since we have long build times, and dont want to make them longer.
regards. David |
|
David,
I have had some build time success by adopting the ninja generator. It's got some dependency issues but it's workable, and though it doesn't solve the relinking issue, it does make builds generally a lot faster. Sent from my iPhone On Oct 24, 2012, at 10:35, DavidAllen <[hidden email]> wrote: > I agree with Leif Walsh.... > > I am currently looking at replacing my unix makefile (linux+gmake, > solaris+make/gmake) and Windows VS projects, with cmake. > > For the makefiles I get gcc to output dependency files based on header file > usage, using gcc options -MM -MF -MP -MT. > > This has worked really well for over a year. If I modify a cpp file that is > used by the shared lib, then the executable does not re-link. If I modify a > .h file that is used by the shared lib *and* the executable, then it WILL > re-link. > > Can I confirm that I cannot replicate this functionality with cmake ? > > If so then this may be a blocker for CMAKE adoption , since we have long > build times, and dont want to make them longer. > > regards. David > > > > -- > View this message in context: http://cmake.3232098.n2.nabble.com/Relink-to-shared-libs-tp7580943p7582156.html > Sent from the CMake mailing list archive at Nabble.com. > -- > > 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 |
|
In reply to this post by DavidAllen
On 2012-10-24 10:35, DavidAllen wrote:
> I am currently looking at replacing my unix makefile (linux+gmake, > solaris+make/gmake) and Windows VS projects, with cmake. > > For the makefiles I get gcc to output dependency files based on header file > usage, using gcc options -MM -MF -MP -MT. > > This has worked really well for over a year. If I modify a cpp file that is > used by the shared lib, then the executable does not re-link. If I modify a > .h file that is used by the shared lib *and* the executable, then it WILL > re-link. I'm not sure that's correct behavior. What if the modification to the .cpp file was to remove the definition of a function declared in a header? Now your executable that was using that function will crash when you try to run it due to a missing symbol. If you had re-linked, you might instead get a link error letting you know something is wrong. You could probably modify CMake to generate build rules that do not treat linked libraries as dependencies for a library/application link step, but I don't think I would consider that correct behavior. -- Matthew -- 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 |
|
Matthew Woehlke <[hidden email]> writes: > I'm not sure that's correct behavior. What if the modification to the > .cpp file was to remove the definition of a function declared in a > header? Now your executable that was using that function will crash when > you try to run it due to a missing symbol. If you had re-linked, you > might instead get a link error letting you know something is wrong. Yes, but this is a very rare thing to do. And the "failure" result is just that the problem would be discovered at test time instead of link time. What's being proposed here is a massive optimization for the common case (changing code in a library and not changing the API or tests) by sacrificing a little bit of latency (the time between link and test) in the extremely rare case. I wouldn't think this would be a hard tradeoff to make. Could it be added at least as an option? -- Cheers, Leif -- 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 |
|
On 10/25/2012 1:17 PM, Leif Walsh wrote:
> Yes, but this is a very rare thing to do. And the "failure" result is > just that the problem would be discovered at test time instead of link > time. > > What's being proposed here is a massive optimization for the common case > (changing code in a library and not changing the API or tests) by > sacrificing a little bit of latency (the time between link and test) in > the extremely rare case. > > I wouldn't think this would be a hard tradeoff to make. Could it be added > at least as an option? you can just build the library target directly with the /fast option or without it. Let's say you have a project with shared library foo and executable bar. You have four options: make foo // build library foo and anything foo depends on make foo/fast // build just foo and nothing it depends on make bar // build bar and anything it depends, with a possible relink when foo changes make // build all targets in the project, will relink bar when foo changes -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 [hidden email] 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 |
|
Is there anything that would convince kitware that the behavior I describe is worth pursuing, even as a non-default option? I'd implement it myself but your code is foreign to me and I bet someone at kitware knows the exact line that needs to change to enable this.
The reason I'm pushing so hard on this is that my project builds several libraries and each is tested individually, and furthermore, each library builds a shared and a static library and there are a few tests that test the static library but most test the shared library. Obviously the statically linked tests cannot use the optimization I described. So if I'm developing, I can't just build one library target always, I may need to build different library targets depending on what code I'm modifying, and in most cases I need to build multiple library targets and a few statically linked tests. Having to do this manually is a big pain, and the natural place to do it is right in the build system, since it already has all the information needed for these decisions. For me, this is a big regression from Make and Autotools. Not big enough to switch back, certainly, but very big. Sent from my iPhone On Oct 25, 2012, at 16:26, Bill Hoffman <[hidden email]> wrote: > On 10/25/2012 1:17 PM, Leif Walsh wrote: >> Yes, but this is a very rare thing to do. And the "failure" result is >> just that the problem would be discovered at test time instead of link >> time. >> >> What's being proposed here is a massive optimization for the common case >> (changing code in a library and not changing the API or tests) by >> sacrificing a little bit of latency (the time between link and test) in >> the extremely rare case. >> >> I wouldn't think this would be a hard tradeoff to make. Could it be added >> at least as an option? > CMake errs on the side of being correct. If you do not want to relink, you can just build the library target directly with the /fast option or without it. > > Let's say you have a project with shared library foo and executable bar. You have four options: > > make foo // build library foo and anything foo depends on > > make foo/fast // build just foo and nothing it depends on > > make bar // build bar and anything it depends, with a possible relink when foo changes > > make // build all targets in the project, will relink bar when foo changes > > > -- > Bill Hoffman > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > [hidden email] > 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 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 |
|
In reply to this post by Leif Walsh
I can't see why you couldn't use set(CMAKE_SKIP_RPATH ON) and post
build copy your library to a path that's on your linker path; have your tests setup to use the system copy of the library instead of the local copy. ~ Doug. On Sat, Aug 4, 2012 at 2:41 AM, Leif Walsh <[hidden email]> wrote: > This is sort of the point of shared libs though, you can update them without relinking everything on your system, unless you're doing something really brain-damaged. > > Is there any way I, as someone who knows my libraries are sane, can prevent this extra work and just resort to a "make clean" if I really screw something up? > > Sent from my iPhone > > On Jul 20, 2012, at 8:28, Andreas Naumann <[hidden email]> wrote: > >> If you are using the Makefile system, then the libraries are newer than your tests, so your tests seems to need an update. >> >> And sometimes programs need relinking, where should the build system now, if you really need the relinking? >> >> >> Am 20.07.2012 14:08, schrieb Leif Walsh: >>> Why, if I make a small change to my shared library, does cmake relink all of my tests to it? It's a shared library, isn't the point that it doesn't need relinking? Seems like a big waste of time. Can I suppress this in any way? >>> >>> Sent from my iPhone >>> -- >>> >>> 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 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 |
|
Because that doesn't retain the dependencies that do the linking the first time around. It's also messy and non-portable.
Sent from my iPhone On Oct 25, 2012, at 21:52, Doug <[hidden email]> wrote: > I can't see why you couldn't use set(CMAKE_SKIP_RPATH ON) and post > build copy your library to a path that's on your linker path; have > your tests setup to use the system copy of the library instead of the > local copy. > > ~ > Doug. > > On Sat, Aug 4, 2012 at 2:41 AM, Leif Walsh <[hidden email]> wrote: >> This is sort of the point of shared libs though, you can update them without relinking everything on your system, unless you're doing something really brain-damaged. >> >> Is there any way I, as someone who knows my libraries are sane, can prevent this extra work and just resort to a "make clean" if I really screw something up? >> >> Sent from my iPhone >> >> On Jul 20, 2012, at 8:28, Andreas Naumann <[hidden email]> wrote: >> >>> If you are using the Makefile system, then the libraries are newer than your tests, so your tests seems to need an update. >>> >>> And sometimes programs need relinking, where should the build system now, if you really need the relinking? >>> >>> >>> Am 20.07.2012 14:08, schrieb Leif Walsh: >>>> Why, if I make a small change to my shared library, does cmake relink all of my tests to it? It's a shared library, isn't the point that it doesn't need relinking? Seems like a big waste of time. Can I suppress this in any way? >>>> >>>> Sent from my iPhone >>>> -- >>>> >>>> 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 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 |
|
In reply to this post by Leif Walsh
Add target property LINK_DEPENDS_NO_SHARED and initialization variable
CMAKE_LINK_DEPENDS_NO_SHARED to enable this behavior. Suggested-by: Leif Walsh <[hidden email]> --- On 08/03/2012 04:57 PM, Leif Walsh wrote: > On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat <[hidden email]> 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); this->SetPropertyDefault("AUTOMOC", 0); this->SetPropertyDefault("AUTOMOC_MOC_OPTIONS", 0); + this->SetPropertyDefault("LINK_DEPENDS_NO_SHARED", 0); this->SetPropertyDefault("LINK_INTERFACE_LIBRARIES", 0); this->SetPropertyDefault("WIN32_EXECUTABLE", 0); this->SetPropertyDefault("MACOSX_BUNDLE", 0); -- 1.7.10.4 -- 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 |
|
Cool, thanks. I'll try this!
Sent from my iPhone On Oct 26, 2012, at 8:43, Brad King <[hidden email]> wrote: > Add target property LINK_DEPENDS_NO_SHARED and initialization variable > CMAKE_LINK_DEPENDS_NO_SHARED to enable this behavior. > > Suggested-by: Leif Walsh <[hidden email]> > --- > > On 08/03/2012 04:57 PM, Leif Walsh wrote: >> On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat <[hidden email]> 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); > this->SetPropertyDefault("AUTOMOC", 0); > this->SetPropertyDefault("AUTOMOC_MOC_OPTIONS", 0); > + this->SetPropertyDefault("LINK_DEPENDS_NO_SHARED", 0); > this->SetPropertyDefault("LINK_INTERFACE_LIBRARIES", 0); > this->SetPropertyDefault("WIN32_EXECUTABLE", 0); > this->SetPropertyDefault("MACOSX_BUNDLE", 0); > -- > 1.7.10.4 > 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 |
|
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 <[hidden email]> writes: > Cool, thanks. I'll try this! > > Sent from my iPhone > > On Oct 26, 2012, at 8:43, Brad King <[hidden email]> wrote: > >> Add target property LINK_DEPENDS_NO_SHARED and initialization variable >> CMAKE_LINK_DEPENDS_NO_SHARED to enable this behavior. >> >> Suggested-by: Leif Walsh <[hidden email]> >> --- >> >> On 08/03/2012 04:57 PM, Leif Walsh wrote: >>> On 3 Aug, 2012, at 4:44 PM, Andreas Pakulat <[hidden email]> 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); >> this->SetPropertyDefault("AUTOMOC", 0); >> this->SetPropertyDefault("AUTOMOC_MOC_OPTIONS", 0); >> + this->SetPropertyDefault("LINK_DEPENDS_NO_SHARED", 0); >> this->SetPropertyDefault("LINK_INTERFACE_LIBRARIES", 0); >> this->SetPropertyDefault("WIN32_EXECUTABLE", 0); >> this->SetPropertyDefault("MACOSX_BUNDLE", 0); >> -- >> 1.7.10.4 >> -- Cheers, Leif -- 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 |
|
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 |
|
In reply to this post by Leif Walsh
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 [hidden email] 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 |
|
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 <[hidden email]> 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 > [hidden email] > 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 |
| Powered by Nabble | Edit this page |
