Re: [cmake-developers] Test fails with Xcode
On Wed, 26 Jun 2013 09:14:51 -0400, Brad King said: > RogueResearch7 Mac10.8-xcode-dbg-x86_64 > http://open.cdash.org/testDetails.php?test=196407273&build=2947399 > clang: error: no such file or directory: '/Users/builder/external/CMake- >xcode-dbg-x86_64/Tests/ExportImport/Import/A/excludedFromAll/Debug/ >libexcludedFromAll.dylib' /Users/builder/external/CMake-xcode-dbg-x86_64/Tests/ExportImport/Import/A/excludedFromAll/ exits, but there is no 'Debug' folder within. >though it may be sporadic. I cannot reproduce it on my OS X 10.8 >machine. In the above-linked output one can see that Xcode does >not build the "excludedFromAll" target prior to the failure. In >my local build it does. Something is tricking your Xcode into not >building the target. > >Please take a look to see if you can identify the problem in your >local build tree. I'm short of time this week, but today I just updated from Xcode 4.6.2 to 4.6.3 and deleted the CMake binary folders for a cleaner build tomorrow. Let's see if that changes something... Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- 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] INTERFACE_LINK_LIBRARIES property?
On 6/26/2013 12:24 PM, Stephen Kelly wrote: > EXPORT_LINK_INTERFACE_LIBRARIES option I think the generated targets file will need to bump its minimum required version of CMake if the policy is NEW and the compatibility export option is not used. Otherwise consuming projects running older CMake versions will silently get through the CMake step and fail at build time. -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] INTERFACE_LINK_LIBRARIES property?
Steve, In this topic we need to distinguish between two types of warnings: * Policy Warnings: Generated using GetPolicyWarning. These should appear only when the policy is not set (WARN), and should be triggered in cases that involve only old-style code that if left unmodified would behave differently when the policy is set to NEW. * Other warnings. These can come from unexpected uses of the new and/or old properties regardless of the policy (non-)setting. On 6/26/2013 12:24 PM, Stephen Kelly wrote: >> It can't be triggered by "new-style" code because the whole >> point of policy warnings is to trigger for old code not yet >> aware of the policy and the preferred new behavior. > > I'm not sure what in particular you're referring to here. Maybe it's the > export case I described above? By "new-style" code I mean code written to use properties introduced in the same version of CMake that introduces the policy. If such code appears in the project then clearly the developers are aware of the new features and presumably the existence of the policy. The purpose of a policy is to preserve behavior for existing project releases that pre-date developers' awareness of the policy and its behavior change. The warning generated when the policy is not set (WARN) needs to be of the form: "CMake now prefers to do something different with this existing code but for compatibility we are doing the old thing. Please update the project to be aware of the preferred behavior and tell us which one to do." In this case old code calling only tll and install(EXPORT) and not setting any properties explicitly will behave the same whether the policy is set to OLD or NEW, except that the properties exposed to external consumers will change. The build of the project itself will not change, and even external consumers will behave the same if they are built with the same version of CMake. I think the case where existing code would produce different behavior if the policy were set to NEW without other changes is when the project sets the old LINK_INTERFACE_LIBRARIES properties directly instead of asking tll() to do it. We may have to re-think the internal handling of the policy WARN behavior in order to identify cases that should trigger a GetPolicyWarning message. Perhaps the following will work: * NEW: tll sets INTERFACE_LINK_LIBRARIES and cmTarget computes the link interface using it. * OLD: tll sets LINK_INTERFACE_LIBRARIES(_) and cmTarget computes the link interface using them. * WARN (not set): Same as OLD, but tll additionally populates a C++-only copy of what *would* have been put in the newer INTERFACE_LINK_LIBRARIES property. Then cmTarget computes what *would* have been the new-style link interface and compares it to the actual link interface computed from the OLD behavior. This comparison will indicate whether the behavior would change and can produce the warning if so. (We could also consider setting INTERFACE_LINK_LIBRARIES instead of using a C++-only copy under the expectation that the project does not know about the property anyway.) With this approach there shouldn't be any policy warnings generated for code that uses only tll(). This is good because such projects do not actually need any modification for the policy's NEW behavior to do the right thing. For code that uses set_property to set LINK_INTERFACE_LIBRARIES(_) directly the warning may trigger, which is good because such projects will need modification for the policy's NEW behavior to do the right thing. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014249]: dylib_compatibility_version and dylib_current_version not set for Fortran libraries
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14249 == Reported By:Graham Markall Assigned To: == Project:CMake Issue ID: 14249 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-06-26 13:27 EDT Last Modified: 2013-06-26 13:27 EDT == Summary:dylib_compatibility_version and dylib_current_version not set for Fortran libraries Description: When a Fortran library is linked, the compatibility and current versions are not set. I believe (from looking at Modules/Platform/Darwin) that the compatibility and current version flags are only set for C and C++, so when cmMakefileLibraryTargetGenerator::AppendOSXVerFlag tries to append the flags for Fortran, it fails because they are not found. I was able to work around this by adding: set(CMAKE_Fortran_OSX_COMPATIBILITY_VERSION_FLAG "-compatibility_version ") set(CMAKE_Fortran_OSX_CURRENT_VERSION_FLAG "-current_version ") to my CMakeLists.txt - but I imagine the correct behaviour would be for these to be set when Fortran is enabled on Darwin. == Issue History Date ModifiedUsername FieldChange == 2013-06-26 13:27 Graham Markall New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test fails with Xcode
On 6/26/2013 12:31 PM, Stephen Kelly wrote: > It calls the virtual cmLocalGenerator::AppendFlags, and > cmLocalUnixMakefileGenerator3::AppendFlags does appropriate escaping, but > the former does not. No, cmLocalUnixMakefileGenerator3::AppendFlags does no escaping except to fix up special cases on Watcom Make to make it work like other make tools. > I think the problem is that there is no cmLocalXCodeGenerator::AppendFlags > override. Given commit 35496761a58956bd8c5ad65a3ed9ee78d09af56b, I think a > similar problem should appear if a similar -DFOO="Bar" is put into the > COMPILE_FLAGS target property. That would confirm that this problem pre- > dates the COMPILE_OPTIONS property. Can you test that? Ahh. COMPILE_FLAGS has *never* been escaped on *any* generator. It is just a raw string to be added to command lines. This is historical and will not be changed, which is one reason we need a new feature like COMPILE_OPTIONS. Part of the value of COMPILE_OPTIONS is supposed to be that it takes a ;-list of options and escapes each one appropriately. You'll have to go back and fix up the generators or cmTarget's GetCompileOptions method to use lg->EscapeForShell when appending each flag. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014248]: Package Manager is deprecated in Xcode 4.6
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14248 == Reported By:Li-Ta Lo Assigned To: == Project:CMake Issue ID: 14248 Category: CPack Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-06-26 12:32 EDT Last Modified: 2013-06-26 12:32 EDT == Summary:Package Manager is deprecated in Xcode 4.6 Description: The default package generator used by CPack on Mac OS is the PackageManager. It is deprecated in Xcode release 4.6 thus not available in newer installation of xcode environment. Please see the Xcode 4.6 release note http://developer.apple.com/library/ios/#releasenotes/developertools/rn-xcode/#//apple_ref/doc/uid/TP40001051-SW241 Steps to Reproduce: One Mac OS X with Xcode 4.6.x, type "make package". CPack complains Package Maker is missing. == Issue History Date ModifiedUsername FieldChange == 2013-06-26 12:32 Li-Ta Lo New Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test fails with Xcode
Brad King wrote: > On 06/26/2013 11:16 AM, Stephen Kelly wrote: >> http://open.cdash.org/testDetails.php?test=196514636&build=2948288 >> >> The unit test seems to be exposing a bug in the Xcode generator or in the >> handling of the COMPILE_OPTIONS target property. Any idea what could be >> going on? > > The generated Xcode project file has > > COMPILER_FLAGS = "-DTEST_C_COMPILER_VERSION=\\"4.1.0\\" ..." > > but it should be > > COMPILER_FLAGS = "-DTEST_C_COMPILER_VERSION=\\\"4.1.0\\\" ..." > > Where is the escaping supposed to happen for the CompileOptions APIs? It calls the virtual cmLocalGenerator::AppendFlags, and cmLocalUnixMakefileGenerator3::AppendFlags does appropriate escaping, but the former does not. I think the problem is that there is no cmLocalXCodeGenerator::AppendFlags override. Given commit 35496761a58956bd8c5ad65a3ed9ee78d09af56b, I think a similar problem should appear if a similar -DFOO="Bar" is put into the COMPILE_FLAGS target property. That would confirm that this problem pre- dates the COMPILE_OPTIONS property. Can you test that? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Brad King wrote:
> On 06/07/2013 09:36 AM, Brad King wrote:
>> Great. One more part to think about is how the warning can work
>> for the interface policy.
> * OLD behavior uses the old properties for everything
> (tll sets them, cmTarget reads them)
> * NEW behavior uses the new property for everything
> (tll sets it, cmTarget reads it)
> When the policy is not set we will use the old behavior, but
> when would we ever warn to ask developers to set the policy?
The current implementation in my clone emits a warning only if the old and
new properties are both set for one target and contain different values.
What other situations should be warned about?
In the new GetTransitivePropertyLinkLibraries() method I have code like
+ if (this->GetPolicyStatusCMP0022() == cmPolicies::WARN
+ || this->GetPolicyStatusCMP0022() == cmPolicies::OLD)
+{
i.e., don't actually emit a warning from this method if the policy is WARN.
This snippet is called only when evaluating generator expressions to get
transitive property values from the link interface. I could check if the new
property is populated there, and emit a warning something along the lines
that 'you are using the old and new properties on the same target', which is
the warning they'd see anyway from cmTarget::ComputeLinkInterface.
Similarly, I emit a warning if the CMP0022 policy is set to NEW, but the
EXPORT_LINK_INTERFACE_LIBRARIES option to export() was not used and the old
properties are populated. This can only happen if the developer incorrectly
reacts to the policy by setting the policy to NEW but not using
EXPORT_LINK_INTERFACE_LIBRARIES and not removing code which causes the old
properties to be populated. So, it's not like a regular 'policy warning'
which is to warn about existing code usage to migrate away from, but still
an author warning that they haven't handled the policy correctly yet
(Actually it's a FATAL_ERROR, not a warning).
> It can't be triggered by "new-style" code because the whole
> point of policy warnings is to trigger for old code not yet
> aware of the policy and the preferred new behavior.
I'm not sure what in particular you're referring to here. Maybe it's the
export case I described above?
> Perhaps we can warn whenever someone sets the old property
> explicitly through set_property or set_target_properties
> such that it would not be mapped by the policy's changes
> to tll behavior. Other ideas?
Such set_property or set_target_properties calls will result in a warning
from cmTarget::ComputeLinkInterface, so I don't understand why another is
needed?
>> We could also warn when someone sets the new-style properties
>> but does not set the policy to NEW.
>
> To clarify, this would be a general warning and not tied to
> complaining when the policy is not set. Obviously such code
> is aware of the new properties already.
Same as above, I'm not sure why another warning would be needed, or I don't
understand what you are suggesting.
I've re-pushed the INTERFACE_LINK_LIBRARIES-prop branch to my clone with a
rebase.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Test fails with Xcode
On 06/26/2013 11:16 AM, Stephen Kelly wrote: > http://open.cdash.org/testDetails.php?test=196514636&build=2948288 > > The unit test seems to be exposing a bug in the Xcode generator or in the > handling of the COMPILE_OPTIONS target property. Any idea what could be > going on? The generated Xcode project file has COMPILER_FLAGS = "-DTEST_C_COMPILER_VERSION=\\"4.1.0\\" ..." but it should be COMPILER_FLAGS = "-DTEST_C_COMPILER_VERSION=\\\"4.1.0\\\" ..." Where is the escaping supposed to happen for the CompileOptions APIs? Also this is failing only on Xcode versions that use GNU but modern ones use Clang. I was able to reproduce the same problem on recent Xcode by hacking the test to use Clang instead of GNU. -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] Test fails with Xcode
Stephen Kelly wrote: > > Hi there, > > The ExportImport test is failing with two Xcode dashboards (but not the > other xcode dashboards) > In an unrelated situation, the CompileOptions test fails for the Xcode continuous dashboard after merging compiler-version-genex, which sets a command line define containing a string. http://open.cdash.org/testDetails.php?test=196514636&build=2948288 The unit test seems to be exposing a bug in the Xcode generator or in the handling of the COMPILE_OPTIONS target property. Any idea what could be going on? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0014247]: CxxTest source files are compiled in Visual Studio 10 though they shouldn't
The following issue has been SUBMITTED. == http://cmake.org/Bug/view.php?id=14247 == Reported By:res3d Assigned To: == Project:CMake Issue ID: 14247 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2013-06-26 10:53 EDT Last Modified: 2013-06-26 10:53 EDT == Summary:CxxTest source files are compiled in Visual Studio 10 though they shouldn't Description: The source files containing the actual test sources (i.e. the input files to test generantion) are compiled as though there were actual source files in Visual Studio 10 if they have a .cpp extension. But since they can't be compiled standalone it would be desireable to have them only show up in the project, but be excluded from actual compilation. This can be done by tagging the test source files as "header files only" (see attached patch). Steps to Reproduce: 1. Create a CxxTest with the input files having an .cpp extension: CXXTEST_ADD_TEST(test_UnicodeStream test_generated.cpp my_test_input.cpp) 2. Generate a Visual Studio 10 project. 3. Compile: my_test_input.cpp is being compiled, which fails. == Issue History Date ModifiedUsername FieldChange == 2013-06-26 10:53 res3d New Issue 2013-06-26 10:53 res3d File Added: cmake-cxxtest-sources-headers-only.patch == -- 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] INTERFACE_LINK_LIBRARIES property?
On 06/07/2013 09:36 AM, Brad King wrote: > Great. One more part to think about is how the warning can work > for the interface policy. In what I proposed: > > * OLD behavior uses the old properties for everything > (tll sets them, cmTarget reads them) > * NEW behavior uses the new property for everything > (tll sets it, cmTarget reads it) > > Note that in the NEW behavior, even the old-style tll > LINK_INTERFACE_LIBRARIES signature will set the new property. > > When the policy is not set we will use the old behavior, but > when would we ever warn to ask developers to set the policy? > It can't be triggered by "new-style" code because the whole > point of policy warnings is to trigger for old code not yet > aware of the policy and the preferred new behavior. > > Perhaps we can warn whenever someone sets the old property > explicitly through set_property or set_target_properties > such that it would not be mapped by the policy's changes > to tll behavior. Other ideas? I'm still not sure what is best to do with the above. > We could also warn when someone sets the new-style properties > but does not set the policy to NEW. To clarify, this would be a general warning and not tied to complaining when the policy is not set. Obviously such code is aware of the new properties already. -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] INTERFACE_LINK_LIBRARIES property?
On 06/26/2013 03:52 AM, Stephen Kelly wrote: > * I think I confused you by working on both the tll signature and the new > property in the same branch in my clone. I split out the tll-new-signatures > topic from INTERFACE_LINK_LIBRARIES-prop topic. Yes, there was some mixing of the commits for the two orthogonal changes. I also added to the confusion by over-using the terms "old" and "new" in my reviews instead of spelling out what I meant. > Option A) Drop the insistence that tll-new-signatures is merged first. > > I can then address your feedback on INTERFACE_LINK_LIBRARIES-prop > > > http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6767/focus=7122 > > and get it merged, then follow up with tll-new-signatures. Okay, let's go with this option. You'll have to start by rebasing the topic since commit bb4260c9 was already put in next and reverted. 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] Test fails with Xcode
On 06/25/2013 04:21 AM, Stephen Kelly wrote: > The ExportImport test is failing with two Xcode dashboards (but not the > other xcode dashboards) > > > http://open.cdash.org/testSummary.php?project=1&name=ExportImport&date=2013-06-25 > http://open.cdash.org/testDetails.php?test=196266835&build=2946532 > > clang: error: no such file or directory: > '/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/ExportImport/Import/A/excludedFromAll/Debug/libexcludedFromAll.a' > > Any idea why that library would not be created in only those two? Sean, this happened on these two builds: RogueResearch7 Mac10.8-xcode-dbg-x86_64 RogueResearch9 Mac10.6-xcode-rel-x86_64 Last night Stephen switched the test to use a shared library and now it fails only on RogueResearch7 Mac10.8-xcode-dbg-x86_64 http://open.cdash.org/testDetails.php?test=196407273&build=2947399 clang: error: no such file or directory: '/Users/builder/external/CMake-xcode-dbg-x86_64/Tests/ExportImport/Import/A/excludedFromAll/Debug/libexcludedFromAll.dylib' though it may be sporadic. I cannot reproduce it on my OS X 10.8 machine. In the above-linked output one can see that Xcode does not build the "excludedFromAll" target prior to the failure. In my local build it does. Something is tricking your Xcode into not building the target. Please take a look to see if you can identify the problem in your local build tree. 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] Test fails with Xcode
Stephen Kelly wrote: > > Hi there, > > The ExportImport test is failing with two Xcode dashboards (but not the > other xcode dashboards) > > http://open.cdash.org/testSummary.php?project=1&name=ExportImport&date=2013-06-25 > http://open.cdash.org/testDetails.php?test=196266835&build=2946532 > > > clang: error: no such file or directory: '/Users/builder/external/CMake- > xcode-dbg- > x86_64/Tests/ExportImport/Import/A/excludedFromAll/Debug/libexcludedFromAll.a' > > Any idea why that library would not be created in only those two? This problem was fixed by converting the library used in the interface from a static to a shared lib. http://open.cdash.org/buildSummary.php?buildid=2947412 The unit test now passes, but the problem remains for those dashboards with static libs and xcode. I can't debug that problem further. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] set_tests_properties and several environment variables
On Tuesday 25 June 2013 16:14:25 David Cole wrote:
> > I have a strange issue with set_tests_properties() and several
> > ENVIRONMENT
> > definitions. Only the last one shows up in the generated ctest file.
> >
>
>
>
> > ...
>
>
>
> >
> > Should I open a bug or is this knows?
> >
>
>
>
> It’s known. In addition to the alternate way you already came up with (which
> is totally valid, and maybe even preferable...), you could also do:
>
> set_tests_properties(
> testsuite
> PROPERTIES
> ENVIRONMENT
> "LD_PRELOAD=${CMAKE_BINARY_DIR}/src/libnss_wrapper.so;NSS_WRAPPER_PASSWD=${
> CMAKE_CURRENT_BINARY_DIR}/passwd;NSS_WRAPPER_GROUP=${CMAKE_CURRENT_BINARY_DI
> R}/group;NSS_WRAPPER_HOSTS=${CMAKE_CURRENT_BINARY_DIR}/hosts"
> )
Thanks David, it isn't documented that it is a ; delimited list. I thought you
need to specify it several times.
-- andreas
--
Andreas Schneider GPG-ID: F33E3FC6
www.cryptomilk.orga...@cryptomilk.org
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] INTERFACE_LINK_LIBRARIES property?
Stephen Kelly wrote: > Anyway, we can let this one sleep for a bit and come back to it all later. Returning to this topic: * I think I confused you by working on both the tll signature and the new property in the same branch in my clone. I split out the tll-new-signatures topic from INTERFACE_LINK_LIBRARIES-prop topic. * The INTERFACE_LINK_LIBRARIES-prop topic is important. Several other topics depend on it, including introduction of the INTERFACE_LIBRARY. * The tll-new-signatures topic is unimportant. Nothing depends on it. It has caused more friction and churn in the discussion so far, and I am certain there is still more to discuss/figure out before merging it. My interest is in the INTERFACE_LINK_LIBRARIES-prop topic. * You insist that tll-new-signatures be merged before INTERFACE_LINK_LIBRARIES-prop. * There is no need or actual value in doing that re-ordering. There is only busy-work of renumbering the policies which is very demotivational. To move beyond this situation: Option A) Drop the insistence that tll-new-signatures is merged first. I can then address your feedback on INTERFACE_LINK_LIBRARIES-prop http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6767/focus=7122 and get it merged, then follow up with tll-new-signatures. Pros: * Can start now * Can get the important branch in first Cons: * Things don't get merged in the order you want Option B) Pull and rewrite Pull my tll-new-signatures branch and renumber/reorder/rewrite at will and push the result where I can get it. When tll-new-signatures is in, I can address the feedback on INTERFACE_LINK_LIBRARIES-prop. Pros: * Things get merged in the order you want * I don't do the re-numbering * You get to write tll-new-signatures as you want it to be. Cons: * Delays INTERFACE_LINK_LIBRARIES-prop until tll-new-signatures is in. Option C) Continue to do nothing. Pros: * Time can be helpful. Cons: * Nothing continues to happen Thanks, Steve -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
