[cmake-developers] [CMake 0014209]: please document CMakeConfigurableFile.in
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14209 == Reported By:mwoehlke Assigned To: == Project:CMake Issue ID: 14209 Category: Documentation Reproducibility:N/A Severity: text Priority: normal Status: new == Date Submitted: 2013-06-07 17:50 EDT Last Modified: 2013-06-07 17:50 EDT == Summary:please document CMakeConfigurableFile.in Description: Every now and then it is useful to be able to write a file at configure time for use as input to some build command, for which it is desirable to not change the time stamp if the content would not change. This appears to be why CMakeConfigurableFile.in exists (or at least, it is being used this way by a number of projects - including, most notably, VXL, VTK and ITK). It would be nice if this usage was documented somewhere, both to make it more discoverable, and as a reassurance to anyone that otherwise stumbles across it that it isn't going to go away in a future version of CMake. == Issue History Date ModifiedUsername FieldChange == 2013-06-07 17:50 mwoehlke 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] Peculiar issue for "NMake Makefiles JOM"
On 6/6/2013 9:44 PM, Alan W. Irwin wrote: In this particular case I have specified gcc using CMAKE_C_COMPILER. That bombs with the message -- Check for working C compiler: z:/home/wine/newstart/MinGW-4.7.2/bin/gcc.exe -- broken Did you look in the CMakeError.log file to see why it fails? -Bill -- 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 2.8.11.1 Released
Some problems were reported with the 2.8.11 release. Thanks to the swift work of Brad King, Stephen Kelly, Rolf Eike Beer and Modestas Vainius, those problems have been fixed. We've prepared a 2.8.11.1 bug fix release to address those issues. The change log page for this bug-fix only release is here: http://public.kitware.com/Bug/changelog_page.php?version_id=113 Please use the latest release from our download page http://cmake.org/cmake/resources/software.html rather than the 2.8.11 builds that we had previously uploaded. Thanks for your support! Changes in CMake 2.8.11.1 (since 2.8.11) -- Brad King (5): ExternalData: Do not re-stage staged object files try_compile: Fix quoting of libraries in generated CMakeLists.txt KWSys: Fix SystemTools::FileIsDirectory with long paths (#14176) FindBoost: Fix handling of \ in input paths (#14179) Xcode: Fix framework search paths in STATIC library targets (#14191) Modestas Vainius (1): Fix test failures caused by regexp-sensitive characters in the build paths Stephen Kelly (9): include_directories: Fix handling of empty or space-only entries try_compile: Trim whitespace from LINK_LIBRARIES entries cmTarget: Remove some hardcoding of transitive property names. GenexEval: Extract a getLinkedTargetsContent from TargetPropertyNode. GenexEval: Fix evaluation of INCLUDE_DIRECTORIES target property. GenexEval: Test evaluation of INCLUDE_DIRECTORIES target property. FindQt4: Don't fail if certain Qt modules are unavailable. Qt4Macros: Handle Qt ActiveX libraries in qt4_use_modules. Genex: Fix the HEAD target used for evaluated expressions -- 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] Peculiar issue for "NMake Makefiles JOM"
On 6/6/2013 9:44 PM, Alan W. Irwin wrote: Assuming you confirm my finding that the "NMake Makefiles JOM" generator does not currently work properly with the MinGW suite of compilers is there some small change in language support that would make that work? I can confirm that I have never attempted to use JOM with gcc. You might be better off with ninja JOM might be VS specific, I don't think I have ever seen nmake used with gcc either. JOM should be a drop in replacement for nmake. -Bill -- 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] Rogue7 dashboards and clang undefined behaviour
On Tue, 4 Jun 2013 13:45:34 -0400, Brad King said:
>> 'CTestTestFdSetSize' is superficially happening in an OS header's macro:
>>
>> static __inline int
>> __darwin_fd_isset(int _n, const struct fd_set *_p)
>> {
>> return (_p->fds_bits[_n/__DARWIN_NFDBITS] & (1<<(_n %
>> __DARWIN_NFDBITS)));
>> }
>>
>> where right right-hand side of the << is apparently 31.
>__DARWIN_NFDBITS is 32.
>>
>> Alas, gdb refuses to give me a backtrace. But there are only 9
>FD_ISSET() in
>> CMake, anyone familiar with this test/code?
>
>The test covers CTest's ability to drive many child processes at once
>so the file descriptor set is getting filled up. The FD_ISSET calls
>in Source/kwsys/ProcessUNIX.c will be the ones triggering this. It
>looks to me like the bug is in the OS header macro because the "1<<"
>should be "1u<<".
Agreed. I'll suppress both these tests and unsuppress them when the libarchive
and Apple people fix their respective bugs.
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?
Brad King wrote: > Currently the INTERFACE_LINK_LIBRARIES-prop topic has > gone through a few iterations due to confusing the two. I just don't agree with that :). There has not been anything unusual about the topic compared to any other topic. The (simpler) topmost commit has been split/revised a few times, but that was never merged to next. The rest of the commits were just updated as normal in response to the dashboard, and as far as I know are merge ready modulo small issues. Anyway, we can let this one sleep for a bit and come back to it all later. 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?
On 06/07/2013 09:20 AM, Stephen Kelly wrote: > Brad King wrote: >> Don't you mean LINK_INTERFACE_LIBRARIES there? > > Yep, I fixed it and pushed it to my clone. 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? We could also warn when someone sets the new-style properties but does not set the policy to NEW. -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 0014208]: Provide build system information query command
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14208 == Reported By:Nils Gladitz Assigned To: == Project:CMake Issue ID: 14208 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-06-07 09:35 EDT Last Modified: 2013-06-07 09:35 EDT == Summary:Provide build system information query command Description: kwsys provides system information query functions in SystemInformation.cxx. CTest queries and transmits system information to CDash but there doesn't seem to be any way for me to access that information from CMake itself. A query command like e.g. get_system_information(TOTAL_VIRTUAL_MEMORY ) would be nice. Personally I'd like to see how much memory the system has available so I can estimate an upper limit of tests that I can run in parallel. It could also render the rather complicated implementation of ProcessorCount.cmake obsolete. == Issue History Date ModifiedUsername FieldChange == 2013-06-07 09:35 Nils Gladitz 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] INTERFACE_LINK_LIBRARIES property?
On 06/07/2013 09:22 AM, Stephen Kelly wrote: > Brad King wrote: > >> Let me request this a third time and more explicitly: please revert >> the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until >> the signature policy is ready. Introduce the signature policy as >> CMP0022. After we've settled that topic and it is clean on the >> dashboard then start again on INTERFACE_LINK_LIBRARIES. > > I've reverted it from next. > > Given the orthogonality, I don't understand why you want the signature > change in first. Renumbering the policies doesn't seem worthwhile. It is a less-invasive change that also introduces the final tll siganture. With those tll updates out of the way we will be able to concentrate more on defining the behavior for the interface policy. Currently the INTERFACE_LINK_LIBRARIES-prop topic has gone through a few iterations due to confusing the two. Let's get the simpler one done first. Also, the signature policy will be useful on its own if for some reason INTERFACE_LINK_LIBRARIES does not get finished for a while. -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?
Brad King wrote: > Let me request this a third time and more explicitly: please revert > the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until > the signature policy is ready. Introduce the signature policy as > CMP0022. After we've settled that topic and it is clean on the > dashboard then start again on INTERFACE_LINK_LIBRARIES. I've reverted it from next. Given the orthogonality, I don't understand why you want the signature change in first. Renumbering the policies doesn't seem worthwhile. 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] target sources property
On 06/07/2013 09:13 AM, Stephen Kelly wrote: >SOURCES $<$:other.cpp> That has been requested as a feature occasionally. I'm not sure it is possible to implement on all the generators though. -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?
Brad King wrote: > On 06/06/2013 07:27 PM, Stephen Kelly wrote: >> Ok. I've added a commit which I think completes the policy CMP0022 and >> the addition of the INTERFACE_LINK_LIBRARIES property. > > One quick comment on the export change: > > + e << "Target \"" << target->GetName() << "\" has policy CMP0022 " > +"enabled, but also has old-style INTERFACE_LINK_LIBRARIES " > +"properties populated, but it was exported without the " > > Don't you mean LINK_INTERFACE_LIBRARIES there? > Yep, I fixed it and pushed it to my clone. 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] target sources property
Brad King wrote:
> On 06/07/2013 08:35 AM, Stephen Kelly wrote:
>> I looked into it a bit and found that the SOURCES target property already
>> exists. I was going to just add
>>
>>
>>
>>
>> +for(std::vector::iterator i = this-
>>> ObjectLibraries.begin();
>> +i != this->ObjectLibraries.end(); ++i)
>> + {
>> + ss << sep;
>> + sep = ";";
>> + ss << "$";
>> + }
>>
>> and make set_source_files_properties ignore entries of the form
>> $, but I wonder if it would be better to create a new
>> property?
>
> I wonder if we can use the SOURCES property but lift the read-only
> restriction by special-casing the property storage similar to how
> you do for include directories. It should know the cmSourceFile*
> internally but present the value as a path to the source file
> as specified by the project in the property value. Then replace
> the ObjectLibraries member with another representation in the
> special SOURCES property storage vector.
>
Yes, that was the plan sort of.
I guess I can't teach set_source_files_properties to ignore generator
expressions entirely, because I guess you'd want to do this:
set_property(TARGET foo APPEND PROPERTY
SOURCES $<$:other.cpp>)
get_target_property(srcs foo SOURCES)
set_source_files_properties(${srcs} PROPERTIES ...)
So I guess set_source_files_properties needs to learn about generator
expressions anyway, and it can skip over $ entries as it
can't do anything useful with them.
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?
On 06/06/2013 07:27 PM, Stephen Kelly wrote: > Ok. I've added a commit which I think completes the policy CMP0022 and the > addition of the INTERFACE_LINK_LIBRARIES property. One quick comment on the export change: + e << "Target \"" << target->GetName() << "\" has policy CMP0022 " +"enabled, but also has old-style INTERFACE_LINK_LIBRARIES " +"properties populated, but it was exported without the " Don't you mean LINK_INTERFACE_LIBRARIES there? -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/07/2013 04:01 AM, Stephen Kelly wrote: > I've pushed the commit to my clone again. It is not as simple as above > because of how the uses of the signatures are recorded, and because I > disallow the use of debug/optimized/general with the new signatures. > > Other than that, I think it's as described. +"Similar target_link_libraries signatures can not be mixed.", Okay, I think we've had some confusion due to differing assumptions about the meaning of "old" and "new" tll signatures. Let me be more explicit. For the signature policy, there are two groups of signatures: * Group A (what I called "old" signatures): target_link_libraries(lhs a b c) target_link_libraries(lhs LINK_INTERFACE_LIBRARIES a b c) * Group B (what I called "new" signatures): target_link_libraries(lhs LINK_PUBLIC a LINK_PRIVATE b LINK_INTERFACE c) target_link_libraries(lhs PUBLIC a PRIVATE b INTERFACE c) The semantics of the two group B signatures are *identical*. There is absolutely ZERO distinction between PUBLIC and LINK_PUBLIC. All signatures in both groups continue to support debug/optimized keywords because their use is pervasive in find modules. Now, the signature policy should have the following behavior: * OLD: Group A *and* group B can be used for one lhs * NEW: Group A *xor* group B can be used for one lhs Let me request this a third time and more explicitly: please revert the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until the signature policy is ready. Introduce the signature policy as CMP0022. After we've settled that topic and it is clean on the dashboard then start again on INTERFACE_LINK_LIBRARIES. 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
[cmake-developers] [CMake 0014207]: with PGI compilers, simple C++ program plus C library project fails to link
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=14207 == Reported By:Greg Eisenhauer Assigned To: == Project:CMake Issue ID: 14207 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2013-06-07 09:01 EDT Last Modified: 2013-06-07 09:01 EDT == Summary:with PGI compilers, simple C++ program plus C library project fails to link Description: Attached is a tar file with two simple source files and a CMake spec. This is a very simple example of a C++ hello world program including a C library. The CMakeList.txt looks like this: add_library(dummy help.c) ADD_EXECUTABLE(main main.cpp) target_link_libraries(main dummy) The C++ program doesn't actually reference the library, so you can try it with or without the target_link_libraries() line. If you try this with the PGI compilers, and include the dummy library you get a link error, "undefined reference to `__zceh_uncaught_exception'". This appears to be because Cmake has spuriously added -lstdc++ to the link line. (A manual link without -lstdc++ works without error.) If you comment out the target_link_libraries(), all is well, -lstdc++ doesn't appear and the link goes fine. Steps to Reproduce: # where CC and cc are PGI compilers on Titan # untar cmake_test.tar cd cmake_test.tar setenv CC cc setenv CXX CC cmake . make Additional Information: -- The C compiler identification is PGI 12.10.0 -- The CXX compiler identification is PGI 12.10.0 I've tested this with cmake 2.8.6, 2.8.10.2, and with a fresh build from GIT. I've tested with all the versions of the PGI compilers available on titan. All combinations show the same problem of spuriously adding -lstdc++ to the link line. I've tested this on sith.ccs.ornl.gov with various versions of cmake and PGI and *CANNOT* duplicate the problem. I don't currently have access to PGI compilers on any other machines, so this may be something specific to Titan. I've dumped all variables and attributes for the two targets, and stdc++ doesn't seem to appear in anything other than CMAKE_C_IMPLICIT_LINK_LIBRARIES. Sorry I haven't been able to duplicate this on anything except titan.ccs.ornl.gov, which is a rather unique and restricted machine, but I know the folks at kitware collaborate there, so hopefully someone can check this out. == Issue History Date ModifiedUsername FieldChange == 2013-06-07 09:01 Greg EisenhauerNew Issue 2013-06-07 09:01 Greg EisenhauerFile Added: cmake_test.tar == -- 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] target sources property
On 06/07/2013 08:35 AM, Stephen Kelly wrote:
> I looked into it a bit and found that the SOURCES target property already
> exists. I was going to just add
>
>
>
>
> +for(std::vector::iterator i = this-
>> ObjectLibraries.begin();
>>
>>
> +i != this->ObjectLibraries.end(); ++i)
>
>
> + {
>
>
> + ss << sep;
>
>
> + sep = ";";
>
>
> + ss << "$";
> + }
>
> and make set_source_files_properties ignore entries of the form
> $, but I wonder if it would be better to create a new
> property?
I wonder if we can use the SOURCES property but lift the read-only
restriction by special-casing the property storage similar to how
you do for include directories. It should know the cmSourceFile*
internally but present the value as a path to the source file
as specified by the project in the property value. Then replace
the ObjectLibraries member with another representation in the
special SOURCES property storage vector.
-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] target sources property
Brad King wrote:
> On 06/07/2013 04:42 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> Oops, yes I meant TARGET_OBJECTS.
>>
>> And what is the trickyness with it?
>
> It is not currently tricky. I'm saying it may be tricky to
> convert the storage over to a sources target property.
> Perhaps it is simpler than I think though. You'll find
> out when you get there :)
>
I looked into it a bit and found that the SOURCES target property already
exists. I was going to just add
+for(std::vector::iterator i = this-
>ObjectLibraries.begin();
>
+i != this->ObjectLibraries.end(); ++i)
+ {
+ ss << sep;
+ sep = ";";
+ ss << "$";
+ }
and make set_source_files_properties ignore entries of the form
$, but I wonder if it would be better to create a new
property?
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] target sources property
On 06/07/2013 04:42 AM, Stephen Kelly wrote: > Brad King wrote: >> Oops, yes I meant TARGET_OBJECTS. > > And what is the trickyness with it? It is not currently tricky. I'm saying it may be tricky to convert the storage over to a sources target property. Perhaps it is simpler than I think though. You'll find out when you get there :) -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] target sources property
Brad King wrote: > On 06/06/2013 11:15 AM, Stephen Kelly wrote: >>> Also it may be tricky due to the way $ is >>> currently handled up front. >> >> You mean TARGET_OBJECTS? It seems to only populate a ObjectLibraries >> container which is later only used at generate-time. Or do you mean >> something else? > > Oops, yes I meant TARGET_OBJECTS. And what is the trickyness with it? 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: > I expected to see things like > > - else if(args[i] == "LINK_PUBLIC") > + else if(args[i] == "PUBLIC" || args[i] == "LINK_PUBLIC") I've pushed the commit to my clone again. It is not as simple as above because of how the uses of the signatures are recorded, and because I disallow the use of debug/optimized/general with the new signatures. Other than that, I think it's as described. 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
