Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/24/2012 08:19 AM, Brad King wrote:
On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
This is now in the export-sets-2 branch on stage, including a basic test.
Comments ? Ok to merge into next ?
Yes, thanks.
This commit is a problem:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21d1619b
--
diff --git a/Tests/ExportImport/Import/A/CMakeLists.txt
b/Tests/ExportImport/Import/A/CMakeLists.txt
index 650af6a..ca7a67a 100644
--- a/Tests/ExportImport/Import/A/CMakeLists.txt
+++ b/Tests/ExportImport/Import/A/CMakeLists.txt
@@ -1,8 +1,9 @@
+# Import targets from the exported install tree.
+include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
+
# Import targets from the exported build tree.
include(${Import_BINARY_DIR}/../Export/ExportBuildTree.cmake)
-# Import targets from the exported install tree.
-include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
# Try referencing an executable imported from the install tree.
add_custom_command(
--
The test has no dependence between exports from the build tree and
exports from the install tree. The new cross-export dependency
finding logic is artificially connecting them.
Export sets created by export() and those created by install()
should be *independent* groups. They cannot cross. It does not
make sense to have a build tree refer to its own install tree or
vice versa.
-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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Friday 28 September 2012, Brad King wrote:
On 09/24/2012 08:19 AM, Brad King wrote:
On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
This is now in the export-sets-2 branch on stage, including a basic
test.
Comments ? Ok to merge into next ?
Yes, thanks.
This commit is a problem:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=21d1619b
--
diff --git a/Tests/ExportImport/Import/A/CMakeLists.txt
b/Tests/ExportImport/Import/A/CMakeLists.txt index 650af6a..ca7a67a 100644
--- a/Tests/ExportImport/Import/A/CMakeLists.txt
+++ b/Tests/ExportImport/Import/A/CMakeLists.txt
@@ -1,8 +1,9 @@
+# Import targets from the exported install tree.
+include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
+
# Import targets from the exported build tree.
include(${Import_BINARY_DIR}/../Export/ExportBuildTree.cmake)
-# Import targets from the exported install tree.
-include(${CMAKE_INSTALL_PREFIX}/lib/exp/exp.cmake)
# Try referencing an executable imported from the install tree.
add_custom_command(
--
The test has no dependence between exports from the build tree and
exports from the install tree. The new cross-export dependency
finding logic is artificially connecting them.
Export sets created by export() and those created by install()
should be *independent* groups. They cannot cross. It does not
make sense to have a build tree refer to its own install tree or
vice versa.
Hmm.
The imported target bld_testExe2lib in ExportBuildTree.cmake links against the
imported target exp_testExe2libImp created in exp.cmake.
So if exp.cmake is included after ExportBuildTree.cmake this imported library
does not exist yet.
This sounds like a real dependency to me, not an artificial one.
So changing the order seems to me like the right thing to do.
How should an imported target created via export() behave in your opinion ?
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/28/2012 01:21 PM, Alexander Neundorf wrote: The imported target bld_testExe2lib in ExportBuildTree.cmake links against the imported target exp_testExe2libImp created in exp.cmake. So if exp.cmake is included after ExportBuildTree.cmake this imported library does not exist yet. This sounds like a real dependency to me, not an artificial one. I wrote the test originally. It is not a real dependency. The exp_ and bld_ namespaces should be completely separate. One is from install(EXPORT). One is from export(). The export() case does some targets first and then the rest of them via export(APPEND): export(TARGETS ... testExe2libImp ... NAMESPACE bld_ FILE ExportBuildTree.cmake) export(TARGETS ... testExe2lib ... NAMESPACE bld_ APPEND FILE ExportBuildTree.cmake) The APPEND mode should be appending to the existing export set with the same namespace. Currently the second call is looking at testExe2lib and trying to find another export that provides its dependency testExe2libImp. It is incorrectly finding the exp_ install(EXPORT) for testExe2libImp. This is where the artificial dependency is getting introduced by the C++ code. So changing the order seems to me like the right thing to do. It is not. It is wrong. The C++ code needs to be fixed. The change to the test needs to be reverted. How should an imported target created via export() behave in your opinion ? I'm saying that an *export set* created by export() should not be something that install(EXPORT) can search while looking for dependencies, and vice versa. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Friday 28 September 2012, Brad King wrote: On 09/28/2012 01:21 PM, Alexander Neundorf wrote: The imported target bld_testExe2lib in ExportBuildTree.cmake links against the imported target exp_testExe2libImp created in exp.cmake. So if exp.cmake is included after ExportBuildTree.cmake this imported library does not exist yet. This sounds like a real dependency to me, not an artificial one. I wrote the test originally. It is not a real dependency. The exp_ and bld_ namespaces should be completely separate. One is from install(EXPORT). One is from export(). Ok, I see. ... working on it. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Friday 28 September 2012, Alexander Neundorf wrote: On Friday 28 September 2012, Brad King wrote: On 09/28/2012 01:21 PM, Alexander Neundorf wrote: The imported target bld_testExe2lib in ExportBuildTree.cmake links against the imported target exp_testExe2libImp created in exp.cmake. So if exp.cmake is included after ExportBuildTree.cmake this imported library does not exist yet. This sounds like a real dependency to me, not an artificial one. I wrote the test originally. It is not a real dependency. The exp_ and bld_ namespaces should be completely separate. One is from install(EXPORT). One is from export(). Ok, I see. ... working on it. There is an updated version now on stage. The behaviour of cmExportBuildFileGenerator now basically is the same as it was before. The collected target exports are not considered at all anymore, error handling and APPEND mode should work again exactly as before. The code for handling missing targets has moved into a virtual function HandleMissingTargets(), which makes it IMO easier to handle all combinations correctly. ComplainAboutMissingTarget() is not virtual anymore now. The test works again as before. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/28/2012 04:21 PM, Alexander Neundorf wrote: There is an updated version now on stage. The behaviour of cmExportBuildFileGenerator now basically is the same as it was before. The collected target exports are not considered at all anymore, error handling and APPEND mode should work again exactly as before. The code for handling missing targets has moved into a virtual function HandleMissingTargets(), which makes it IMO easier to handle all combinations correctly. ComplainAboutMissingTarget() is not virtual anymore now. The test works again as before. Thanks. I amended the commit to fix some indentation. Then I merged it to 'next' for testing. After this the install(EXPORT) sets will chain automatically. However, export() will not because nothing records the build tree exports globally at all. I think this is okay for now. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/28/2012 04:56 PM, Brad King wrote: On 09/28/2012 04:21 PM, Alexander Neundorf wrote: There is an updated version now on stage. The behaviour of cmExportBuildFileGenerator now basically is the same as it was before. The collected target exports are not considered at all anymore, error handling and APPEND mode should work again exactly as before. The code for handling missing targets has moved into a virtual function HandleMissingTargets(), which makes it IMO easier to handle all combinations correctly. ComplainAboutMissingTarget() is not virtual anymore now. The test works again as before. Thanks. I amended the commit to fix some indentation. Then I merged it to 'next' for testing. After this the install(EXPORT) sets will chain automatically. However, export() will not because nothing records the build tree exports globally at all. I think this is okay for now. After rewriting the generator-expression-target-properties topic I was able to rewrite/squash the export-sets-2 topic and replace it with a new export-sets topic that does not merge in the generator-expression-target-properties changes at all. I removed the export-sets-2 topic from the stage. The export-sets topic makes an identical change. If further changes are needed please check out that branch and commit there. Do not add any more commits to the original export-sets-2 history. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/23/2012 01:22 PM, Alexander Neundorf wrote: This is now in the export-sets-2 branch on stage, including a basic test. Comments ? Ok to merge into next ? Yes, 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Friday 21 September 2012, Alexander Neundorf wrote:
On Thursday 20 September 2012, Brad King wrote:
On 09/20/2012 12:20 PM, Alexander Neundorf wrote:
if(NOT TARGET Foo)
if(CMAKE_FIND_PACKAGE_NAME)
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
What happens if other imported targets have already been defined?
Then the targets file will have been partially loaded.
Yes.
Is this a problem ?
If some find-module searches several libraries, and finds only some of
them, those FOO_LIBRARY variables which have been found also stay set, and
are not reset, but the overall result is NOTFOUND.
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
The required target Foo does not exist !)
else()
message(STATUS
Warning: the required target Foo does not exist !)
endif()
endif()
or SEND_ERROR or FATAL_ERROR ?
I think FATAL_ERROR. It is always easier to lessen this later.
Ok.
This is now in the export-sets-2 branch on stage, including a basic test.
Comments ? Ok to merge into next ?
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Thursday 20 September 2012, Brad King wrote:
On 09/20/2012 12:20 PM, Alexander Neundorf wrote:
if(NOT TARGET Foo)
if(CMAKE_FIND_PACKAGE_NAME)
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
What happens if other imported targets have already been defined?
Then the targets file will have been partially loaded.
Yes.
Is this a problem ?
If some find-module searches several libraries, and finds only some of them,
those FOO_LIBRARY variables which have been found also stay set, and are not
reset, but the overall result is NOTFOUND.
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
The required target Foo does not exist !)
else()
message(STATUS
Warning: the required target Foo does not exist !)
endif()
endif()
or SEND_ERROR or FATAL_ERROR ?
I think FATAL_ERROR. It is always easier to lessen this later.
Ok.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/19/2012 04:14 PM, Alexander Neundorf wrote: On Wednesday 19 September 2012, Alexander Neundorf wrote: Hmm, I was almost done implementing it... when creating the export file, we do not know how the Config file will be named, i.e. we do not know the name of the package, so we cannot set package_FOUND to FALSE... Am I missing something ? cmFindPackage could set a CMAKE_FIND_PACKAGE_NAME variable, which I could use then... Okay with me, but target files may not always be loaded from Config files under find_package. Some projects may load them in other contexts. If CMAKE_FIND_PACKAGE_NAME or one of the other variables you need to detect the case is not set then we need to do something else (error, warning?). -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Thursday 20 September 2012, Brad King wrote:
On 09/19/2012 04:14 PM, Alexander Neundorf wrote:
On Wednesday 19 September 2012, Alexander Neundorf wrote:
Hmm, I was almost done implementing it...
when creating the export file, we do not know how the Config file will
be named, i.e. we do not know the name of the package, so we cannot set
package_FOUND to FALSE...
Am I missing something ?
cmFindPackage could set a CMAKE_FIND_PACKAGE_NAME variable, which I could
use then...
Okay with me, but target files may not always be loaded from Config
files under find_package. Some projects may load them in other
contexts. If CMAKE_FIND_PACKAGE_NAME or one of the other variables
you need to detect the case is not set then we need to do something
else (error, warning?).
Like this ?
if(NOT TARGET Foo)
if(CMAKE_FIND_PACKAGE_NAME)
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
The required target Foo does not exist !)
else()
message(STATUS
Warning: the required target Foo does not exist !)
endif()
endif()
or SEND_ERROR or FATAL_ERROR ?
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/20/2012 12:20 PM, Alexander Neundorf wrote:
if(NOT TARGET Foo)
if(CMAKE_FIND_PACKAGE_NAME)
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
What happens if other imported targets have already been defined?
Then the targets file will have been partially loaded.
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
The required target Foo does not exist !)
else()
message(STATUS
Warning: the required target Foo does not exist !)
endif()
endif()
or SEND_ERROR or FATAL_ERROR ?
I think FATAL_ERROR. It is always easier to lessen this later.
-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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Tuesday 18 September 2012, Brad King wrote: On 09/18/2012 04:12 PM, Alexander Neundorf wrote: How about defining a variable which can be set by Config-files which holds an error message for the case that the Config-file has set package_FOUND to FALSE ? Like e.g. package_FIND_FAILURE_MESSAGE ? This could then be printed by cmFindPackage and/or FPHSA ? It sounds okay to me. Hmm, I was almost done implementing it... when creating the export file, we do not know how the Config file will be named, i.e. we do not know the name of the package, so we cannot set package_FOUND to FALSE... Am I missing something ? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Wednesday 19 September 2012, Alexander Neundorf wrote: On Tuesday 18 September 2012, Brad King wrote: On 09/18/2012 04:12 PM, Alexander Neundorf wrote: How about defining a variable which can be set by Config-files which holds an error message for the case that the Config-file has set package_FOUND to FALSE ? Like e.g. package_FIND_FAILURE_MESSAGE ? This could then be printed by cmFindPackage and/or FPHSA ? It sounds okay to me. Hmm, I was almost done implementing it... when creating the export file, we do not know how the Config file will be named, i.e. we do not know the name of the package, so we cannot set package_FOUND to FALSE... Am I missing something ? cmFindPackage could set a CMAKE_FIND_PACKAGE_NAME variable, which I could use then... 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Alexander Neundorf wrote: On Monday 17 September 2012, Alexander Neundorf wrote: On Monday 17 September 2012, Brad King wrote: On 09/15/2012 04:45 PM, Alexander Neundorf wrote: There is now a branch export-sets-2 on cmake stage. It cherry-picks a lot of the patches from http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly those from May, and then proceeds a bit differently. In the end, cmake now checks whether a target which is missing in the current export set has been exported and installed exactly once, gets the correct name from that one installation (i.e. the used namespace), and uses that. That simple approach will allow us to move forward with this. If anyone wants multiple exports of the same targets then they can add the explicit export set DEPENDS options later. Cool. The tests are not yet passing, I'll work on this. The tests are passing now. I had to change the order how the target files are included in the test, so that the required targets already exist when the other targets are set up. I pushed that to stage too. I think basically we're back to generating useful error messages again... How about defining a variable which can be set by Config-files which holds an error message for the case that the Config-file has set package_FOUND to FALSE ? Like e.g. package_FIND_FAILURE_MESSAGE ? This could then be printed by cmFindPackage and/or FPHSA ? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/18/2012 04:12 PM, Alexander Neundorf wrote: How about defining a variable which can be set by Config-files which holds an error message for the case that the Config-file has set package_FOUND to FALSE ? Like e.g. package_FIND_FAILURE_MESSAGE ? This could then be printed by cmFindPackage and/or FPHSA ? It sounds okay to me. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/15/2012 04:45 PM, Alexander Neundorf wrote: There is now a branch export-sets-2 on cmake stage. It cherry-picks a lot of the patches from http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly those from May, and then proceeds a bit differently. In the end, cmake now checks whether a target which is missing in the current export set has been exported and installed exactly once, gets the correct name from that one installation (i.e. the used namespace), and uses that. That simple approach will allow us to move forward with this. If anyone wants multiple exports of the same targets then they can add the explicit export set DEPENDS options later. The topic looks good except for the details below. Additionally it puts the following check in the generated target file: IF(NOT TARGET Foo::foo ) MESSAGE(FATAL_ERROR Required imported target \Foo::foo\ not found ! ) ENDIF() Please review the branch. Exotic cases are not supported, but it should be possible now to export libraries in separate export sets and still have it work. I guess I have to handle the error case better than simply erroring out. Not IMO. Remember my message here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4374/focus=4386 The user has the option to specify a known-working pkg_DIR value or disable use of the package completely. Your commit message sentence I guess instead of completely erroring out it would be better to only make the find_package() fail. is not needed. Also, one of Yury's commit messages says: TODO: remove another clear() because it doesn't delete TargetExports. What is that about? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
2012/9/17 Brad King brad.k...@kitware.com: On 09/15/2012 04:45 PM, Alexander Neundorf wrote: Also, one of Yury's commit messages says: TODO: remove another clear() because it doesn't delete TargetExports. What is that about? clear() on a vector of TargetExport* does not call delete on each element. BTW, do we really support the reinitialization of all cmake structures? I think that there are quite a few memory leaks in this case. -- Yours Yury, mailto: urkud.ur...@gmail.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: On 09/15/2012 04:45 PM, Alexander Neundorf wrote: There is now a branch export-sets-2 on cmake stage. It cherry-picks a lot of the patches from http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly those from May, and then proceeds a bit differently. In the end, cmake now checks whether a target which is missing in the current export set has been exported and installed exactly once, gets the correct name from that one installation (i.e. the used namespace), and uses that. That simple approach will allow us to move forward with this. If anyone wants multiple exports of the same targets then they can add the explicit export set DEPENDS options later. Cool. The tests are not yet passing, I'll work on this. The topic looks good except for the details below. Additionally it puts the following check in the generated target file: IF(NOT TARGET Foo::foo ) MESSAGE(FATAL_ERROR Required imported target \Foo::foo\ not found ! ) ENDIF() Please review the branch. Exotic cases are not supported, but it should be possible now to export libraries in separate export sets and still have it work. I guess I have to handle the error case better than simply erroring out. Not IMO. Remember my message here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/4374/focu s=4386 The user has the option to specify a known-working pkg_DIR value or disable use of the package completely. Your commit message sentence I guess instead of completely erroring out it would be better to only make the find_package() fail. is not needed. I think this is different. Here, in this case, it may fail because the required (missing) package was simply not found, because it is not installed. If the package is optional, this is ok, cmake should not abort, but just report that the package was not found. In the referenced email, if the error occurs, something is broken on the system, a broken package has been installed, or something like that. This is IMO different than simply a missing package. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/17/2012 03:14 PM, Alexander Neundorf wrote: On Monday 17 September 2012, Brad King wrote: I guess I have to handle the error case better than simply erroring out. Not IMO. Remember my message here: I think this is different. Here, in this case, it may fail because the required (missing) package was simply not found, because it is not installed. I must not understand the use case. It looks to me like you're generating a pkgTargets.cmake file to be loaded by a pkgConfig.cmake file. If these files are being read then pkg_DIR is set to a copy of the pkg. The package has been found. Just as in the previous discussion, the error in the package occurs because it is misconfigured: one of its dependencies is not installed or loaded correctly to provide the other imported target. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: On 09/17/2012 03:14 PM, Alexander Neundorf wrote: On Monday 17 September 2012, Brad King wrote: I guess I have to handle the error case better than simply erroring out. Not IMO. Remember my message here: I think this is different. Here, in this case, it may fail because the required (missing) package was simply not found, because it is not installed. I must not understand the use case. It looks to me like you're generating a pkgTargets.cmake file to be loaded by a pkgConfig.cmake file. If these files are being read then pkg_DIR is set to a copy of the pkg. The package has been found. Just as in the previous discussion, the error in the package occurs because it is misconfigured: one of its dependencies is not installed or loaded correctly to provide the other imported target. Let's say FooTargets.cmake provides the target foo. BarTargets.cmake provides the target bar, and requires FooTargets.cmake. Now if the user installed the bar-devel package, but not the foo-devel package, the target foo will not be available. This can or should be checked also outside maybe in the BarConfig.cmake cmake, which could load BarTargets.cmake only if Foo could be found, but still I think it's not necessary to abort in this error case. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/17/2012 03:35 PM, Alexander Neundorf wrote: Let's say FooTargets.cmake provides the target foo. BarTargets.cmake provides the target bar, and requires FooTargets.cmake. Now if the user installed the bar-devel package, but not the foo-devel package, the target foo will not be available. This can or should be checked also outside maybe in the BarConfig.cmake cmake, which could load BarTargets.cmake only if Foo could be found, but still I think it's not necessary to abort in this error case. What would you do instead of aborting? Silently pretend the package Bar was not found at the current Bar_DIR and move on with the search? That would require the sandboxing I previously elaborated. It would also be confusing to users IMO because the package they know is in their search path would be skipped for a mysterious reason. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: On 09/17/2012 03:35 PM, Alexander Neundorf wrote: Let's say FooTargets.cmake provides the target foo. BarTargets.cmake provides the target bar, and requires FooTargets.cmake. Now if the user installed the bar-devel package, but not the foo-devel package, the target foo will not be available. This can or should be checked also outside maybe in the BarConfig.cmake cmake, which could load BarTargets.cmake only if Foo could be found, but still I think it's not necessary to abort in this error case. What would you do instead of aborting? Silently pretend the package Bar was not found at the current Bar_DIR and move on with the search? That would require the sandboxing I previously elaborated. It would also be confusing to users IMO because the package they know is in their search path would be skipped for a mysterious reason. Isn't e.g. FindPNG.cmake doing just the same ? If zlib wasn't found, fail at finding png. Here we are again at generating error messages... Instead of simply stating that a required target does not exist, it could also state from which installed export this is expected to come, e.g. FooTargets.cmake. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/17/2012 03:52 PM, Alexander Neundorf wrote: On Monday 17 September 2012, Brad King wrote: What would you do instead of aborting? Silently pretend the package Bar was not found at the current Bar_DIR and move on with the search? That would require the sandboxing I previously elaborated. It would also be confusing to users IMO because the package they know is in their search path would be skipped for a mysterious reason. Isn't e.g. FindPNG.cmake doing just the same ? If zlib wasn't found, fail at finding png. Okay, so then BarConfig.cmake would set Bar_FOUND to false to pretend the package isn't found but not change Bar_DIR? Instead of simply stating that a required target does not exist, it could also state from which installed export this is expected to come, e.g. FooTargets.cmake. That would be useful if the namespace doesn't match. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Brad King wrote: On 09/15/2012 04:45 PM, Alexander Neundorf wrote: There is now a branch export-sets-2 on cmake stage. It cherry-picks a lot of the patches from http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly those from May, and then proceeds a bit differently. In the end, cmake now checks whether a target which is missing in the current export set has been exported and installed exactly once, gets the correct name from that one installation (i.e. the used namespace), and uses that. That simple approach will allow us to move forward with this. If anyone wants multiple exports of the same targets then they can add the explicit export set DEPENDS options later. The topic looks good except for the details below. How should the APPEND mode of EXPORT() be handled ? Could you please have a look at cmExportFileGenerator::SetImportLinkProperty(..) whether this looks ok ? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Mon, Sep 17, 2012 at 4:35 PM, Alexander Neundorf neund...@kde.org wrote: How should the APPEND mode of EXPORT() be handled ? Could you please have a look at cmExportFileGenerator::SetImportLinkProperty(..) whether this looks ok ? The APPEND mode used to mean the project is on its own to handle dependencies. I guess it can get the target from another export if it is already there but otherwise not produce any error. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On Monday 17 September 2012, Alexander Neundorf wrote: On Monday 17 September 2012, Brad King wrote: On 09/15/2012 04:45 PM, Alexander Neundorf wrote: There is now a branch export-sets-2 on cmake stage. It cherry-picks a lot of the patches from http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly those from May, and then proceeds a bit differently. In the end, cmake now checks whether a target which is missing in the current export set has been exported and installed exactly once, gets the correct name from that one installation (i.e. the used namespace), and uses that. That simple approach will allow us to move forward with this. If anyone wants multiple exports of the same targets then they can add the explicit export set DEPENDS options later. Cool. The tests are not yet passing, I'll work on this. The tests are passing now. I had to change the order how the target files are included in the test, so that the required targets already exist when the other targets are set up. I pushed that to stage too. I think basically we're back to generating useful error messages again... 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
Hi Yury, On Thursday 23 August 2012, Yury G. Kudryashov wrote: Hi! 2012/8/23 Daniel Pfeifer dan...@pfeifer-mail.de: 2012/8/22 Yury G. Kudryashov urkud.ur...@gmail.com: Any latest install strategy is bound to generate subtle problems. Dependencies among export sets should be explicit: install(EXPORT MyExport DEPENDS YourExport) How should I choose between different install(EXPORT YourExport) commands? What about: install(EXPORT MyExport DEPENDS YourPackage1 YourPackage2) ? That could create: if(NOT __MyExport_include_guard) set(__MyExport_included TRUE) find_package(YourPackage1) find_package(YourPackage2) endif() before declaring the imported targets. That way, we get the package dependencies resolved transitively. This does not solve the problem of resolving namespaces. What do you think about the following algorithm: 1. Export set lookup 1a. Look in the current export set. 1b. If failed, look in the export sets listed in DEPENDS parameter. 1c. If failed, look if the target belongs to a unique export set. 1d. If failed, produce an error message. 2. Installation of an export set lookup. 2a. For the current export set, use the current installation. 2b. For dependencies, if an export set was not installed or was installed more than once, fail; otherwise, use the unique installation. Some questions: 1. What should we do in the APPEND mode? 2. Should we include(/path/to/dependency)? Or find_package() as suggested by Daniel? 2a. If yes, using relative or absolute path? will you be able to work on this for the 2.8.10 release ? This would be great. If not, no problem, but please let us know, so either Stephen or me can give it a try. Thanks :-) 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
2012/9/11 Alexander Neundorf neund...@kde.org: Hi Yury, will you be able to work on this for the 2.8.10 release ? What are the deadlines? -- Yours Yury, mailto: urkud.ur...@gmail.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 09/11/2012 04:08 PM, Yury G. Kudryashov wrote: 2012/9/11 Alexander Neundorf neund...@kde.org: Hi Yury, will you be able to work on this for the 2.8.10 release ? What are the deadlines? Features not finished by the end of September may not be included. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
Hi! 2012/8/23 Daniel Pfeifer dan...@pfeifer-mail.de: 2012/8/22 Yury G. Kudryashov urkud.ur...@gmail.com: Any latest install strategy is bound to generate subtle problems. Dependencies among export sets should be explicit: install(EXPORT MyExport DEPENDS YourExport) How should I choose between different install(EXPORT YourExport) commands? What about: install(EXPORT MyExport DEPENDS YourPackage1 YourPackage2) ? That could create: if(NOT __MyExport_include_guard) set(__MyExport_included TRUE) find_package(YourPackage1) find_package(YourPackage2) endif() before declaring the imported targets. That way, we get the package dependencies resolved transitively. This does not solve the problem of resolving namespaces. What do you think about the following algorithm: 1. Export set lookup 1a. Look in the current export set. 1b. If failed, look in the export sets listed in DEPENDS parameter. 1c. If failed, look if the target belongs to a unique export set. 1d. If failed, produce an error message. 2. Installation of an export set lookup. 2a. For the current export set, use the current installation. 2b. For dependencies, if an export set was not installed or was installed more than once, fail; otherwise, use the unique installation. Some questions: 1. What should we do in the APPEND mode? 2. Should we include(/path/to/dependency)? Or find_package() as suggested by Daniel? 2a. If yes, using relative or absolute path? -- Yours Yury, mailto: urkud.ur...@gmail.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 08/23/2012 04:20 AM, Yury G. Kudryashov wrote:
Hi!
2012/8/23 Daniel Pfeifer dan...@pfeifer-mail.de:
2012/8/22 Yury G. Kudryashov urkud.ur...@gmail.com:
Any latest install strategy is bound to generate subtle problems.
Dependencies among export sets should be explicit:
install(EXPORT MyExport DEPENDS YourExport)
How should I choose between different
install(EXPORT YourExport)
commands?
I don't think we ever considered the possibility of more than one
install(EXPORT) for the same export, only that there could be more
than one install(TARGETS ... EXPORT ...) for the same target but
listing different exports. I would be okay with warning if there
is more than one install for the same export and making it an error
if the export is a dependency of another export (your algo #2).
1. Export set lookup
1a. Look in the current export set.
1b. If failed, look in the export sets listed in DEPENDS parameter.
1c. If failed, look if the target belongs to a unique export set.
1d. If failed, produce an error message.
That looks good, though I'm not excited by 1c. I'd rather all
DEPENDS be explicit so there are no surprises. What if I had
intended to put the dependency in my current set but forgot?
2. Installation of an export set lookup.
2a. For the current export set, use the current installation.
2b. For dependencies, if an export set was not installed or was
installed more than once, fail; otherwise, use the unique
installation.
Yes.
Some questions:
1. What should we do in the APPEND mode?
That does not check dependencies anyway so the project doing that
is on its own. A better approach is to APPEND to a global property
and then do one export() at the end by querying the global property.
2. Should we include(/path/to/dependency)? Or find_package() as
suggested by Daniel?
2a. If yes, using relative or absolute path?
No, at least not yet. I think Alex's suggestion:
if(NOT TARGET mydep)
message(FATAL_ERROR mydep not found; need ${export_providing_mydep})
endif()
is the simplest approach. The file produced by install(EXPORT)
is not necessarily a package configuration file itself but
should normally be loaded by one. We do not know what the package
on which we depend will be called.
Normally there will be a package configuration file that loads the
current export. It is up to that file to ensure that it has loaded
the packages that load the current export's dependencies.
-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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 08/22/2012 04:15 PM, Alexander Neundorf wrote: add_library(foo SHARED foo.c) install(TARGETS foo EXPORT FooExport DESTINATION lib ) install(TARGETS foo EXPORT FooExportX DESTINATION libx ) install(EXPORT FooExport DESTINATION lib/foo ) install(EXPORT FooExport NAMESPACE Foo:: DESTINATION lib/foo2 ) install(EXPORT FooExportX DESTINATION lib/fooX ) add_library(bar SHARED bar.c) target_link_libraries(bar foo) install(TARGETS bar EXPORT BarExport DESTINATION lib ) install(EXPORT BarExport NAMESPACE Xyz:: DESTINATION lib/bar ) If I would do this, I would get the error for the BarExport export set, that it does not contain target foo, which it depends on. We'd like to make this work, since we need this in KDE. Didn't we discuss that here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2833/focus=2968 ? We need to allow export sets to depend on other export sets to get their dependencies? The namespace of the dependency will then be known. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
Hi, 2012/8/23 Alexander Neundorf neund...@kde.org: Hi, If I would do this, I would get the error for the BarExport export set, that it does not contain target foo, which it depends on. We'd like to make this work, since we need this in KDE. How can this be done ? Sorry for the very long silence. I had rather rich real life (e.g., my son born about a month ago). Here's a relatively simple (I think) idea: export it anyway, and make sure in the generated targets file that those targets which were not part of the export-set exist: I'm going to push the current state of my work to git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git w/export-set in a few minutes. It should work, though I haven't tested it yet. The idea is simple: each target remembers the latest install(TARGETS ... EXPORT) command, and each export set remembers teh latest install(EXPORT MyExport) command. Then we query this information. There is an issue with the used namespace. Maybe it could simply assume that the targets which are not present use the same namespace as it does itself (as shown in the example above) ? Also, CMake could still error out if it detects that a library which an exported library depends on, is not exported at all, also taking into account the namespace. Would that work ? Did I miss something ? Better ideas ? Alex -- Yours Yury, mailto: urkud.ur...@gmail.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
On 08/22/2012 04:57 PM, Yury G. Kudryashov wrote: I'm going to push the current state of my work to git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git w/export-set in a few minutes. Thanks for working on this! It should work, though I haven't tested it yet. The idea is simple: each target remembers the latest install(TARGETS ... EXPORT) command, and each export set remembers teh latest install(EXPORT MyExport) command. Then we query this information. Any latest install strategy is bound to generate subtle problems. Dependencies among export sets should be explicit: install(EXPORT MyExport DEPENDS YourExport) If a target in MyExport depends on a target not in the export set then look at YourExport for it. If the target's dependency is still not found we can search for other export sets containing it and suggest one in the error message. -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
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
2012/8/23 Brad King brad.k...@kitware.com: On 08/22/2012 04:57 PM, Yury G. Kudryashov wrote: I'm going to push the current state of my work to git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git w/export-set in a few minutes. Thanks for working on this! It should work, though I haven't tested it yet. The idea is simple: each target remembers the latest install(TARGETS ... EXPORT) command, and each export set remembers teh latest install(EXPORT MyExport) command. Then we query this information. Any latest install strategy is bound to generate subtle problems. Dependencies among export sets should be explicit: install(EXPORT MyExport DEPENDS YourExport) How should I choose between different install(EXPORT YourExport) commands? -- Yours Yury, mailto: urkud.ur...@gmail.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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Exporting dependent library targets in multiple export sets
2012/8/22 Yury G. Kudryashov urkud.ur...@gmail.com: 2012/8/23 Brad King brad.k...@kitware.com: On 08/22/2012 04:57 PM, Yury G. Kudryashov wrote: I'm going to push the current state of my work to git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git w/export-set in a few minutes. Thanks for working on this! It should work, though I haven't tested it yet. The idea is simple: each target remembers the latest install(TARGETS ... EXPORT) command, and each export set remembers teh latest install(EXPORT MyExport) command. Then we query this information. Any latest install strategy is bound to generate subtle problems. Dependencies among export sets should be explicit: install(EXPORT MyExport DEPENDS YourExport) How should I choose between different install(EXPORT YourExport) commands? What about: install(EXPORT MyExport DEPENDS YourPackage1 YourPackage2) ? That could create: if(NOT __MyExport_include_guard) set(__MyExport_included TRUE) find_package(YourPackage1) find_package(YourPackage2) endif() before declaring the imported targets. That way, we get the package dependencies resolved transitively. Cheers, Daniel -- 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
