Brad King wrote:
Note that your generator expression evaluation in imported targets
will still need to handle MAP_IMPORTED_CONFIG_CONFIG correctly.
This was easy as most of the API changes were already written in a different
commit.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit
Hi,
I'm again quite confused by how many things you now want to change compared
to what we were discussing before.
I'll try again to deal with it in b(y|i)tesize chunks.
Brad King wrote:
For STATIC libraries we can
define that the PUBLIC/PRIVATE/INTERFACE keys are ignored for
linking and
Stephen Kelly wrote:
I'll try again to deal with it in b(y|i)tesize chunks.
I thought I should write a high-level email too.
All of your proposed changes to the plumbing are difficult to understand
because you don't relate what you are proposing to what we had discussed and
understood before
Brad King wrote:
When the property is not set (internally it is WARN) then tll()
s/property/policy/ ?
s/internally/initially/ ?
will populate both the old and new properties. ComputeLinkInfo
do you mean cmComputeLinkDepends?
will compute both the old and new style link interfaces, warn if
Brad King wrote:
Now, on to exporting. Unlike the previous iteration the policy
affects it too.
When the policy is OLD/WARN we export only the old interface and
not the new interface.
We spent some time figuring out how to not export the old interface if it is
not needed, based only on
Stephen Kelly wrote:
I'd like to defer the details of the
porcelain API for now and focus instead on the plumbing API and
implementation.
I have several quirks with the new command proposal, The new command can be
emulated with my branch and this macro:
include(CMakeParseArguments
Hi there (Alex/Clinton),
I've added a branch to the stage to list public link depends of Qt modules.
Please review it before I merge it to next.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
clin...@elemtech.com wrote:
I'm already aware of the distinction.
Great. That wasn't clear from your email talking about all dependencies of
QtDeclarative instead of just the public ones.
Granted, UseQt4.cmake doesn't know
if imported targets are being used or not, and probably cannot be
Hi there,
Currently the new Qt4Targets test I wrote is running on many linux and mac,
but is failing on the SLED LSB platforms.
http://open.cdash.org/testSummary.php?project=1name=Qt4Targetsdate=2013-01-03
The test is essentially testing that the LINK_INTERFACE_LIBRARIES property
on the Qt4
Stephen Kelly steveire@... writes:
Is this email enough of a report about that, or do you want a tracker entry?
Any response to this?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep
David Cole wrote:
That has now been merged to master of kwsys:
http://review.source.kitware.com/#/c/9043/
It will appear in CMake soon.
I guess I should have quoted more context.
I was not talking about the patch. I was talking about the -Wundef issue and
the kwsys issue that it
Hi there,
While the porcelain API for setting includes and defines is somewhat
controversial, the plumbing is not, as far as I can tell. I previously wrote
that I'd like to get all of the INTERFACE_* related commits in together, but
I don't think that matters so much really. I'd prefer to get
Brad King wrote:
On 01/03/2013 12:12 PM, Stephen Kelly wrote:
I was not talking about the patch. I was talking about the -Wundef issue
and the kwsys issue that it exposes:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5665/focus=5672
http://review.source.kitware.com
Shlomi Fish wrote:
Hi all,
following a discussion we had on ##llvm on irc.oftc.net (the main LLVM
channel, because LLVM+clang can be built using CMake), I've been wondering
if you would like someone (like me) to implement an interactive debugger
(or debugging mode) for cmake invocations,
Stephen Kelly wrote:
Brad King wrote:
* In the Use mapped config properties to evaluate $CONFIG you add
code
to handle MAP_IMPORTED_CONFIG. I think that should be an API on
cmTarget refactored from its existing imported config selection code.
You mean you want the $CONFIG:mappedCfg
Stephen Kelly wrote:
If, you agree, I'll merge this to next.
I've also pushed a LINK_LIBRARIES-property branch, and a
INTERFACE_LINK_LIBRARIES-genex branch to gitorious.
If you can review them and tell me they're fine, modulo what the dashboard
says, I can have them dashboard-clean and we
Brad King wrote:
On 01/04/2013 10:15 AM, Stephen Kelly wrote:
I've also pushed a LINK_LIBRARIES-property branch, and a
INTERFACE_LINK_LIBRARIES-genex branch to gitorious.
s/INTERFACE_LINK_LIBRARIES/LINK_INTERFACE_LIBRARIES/ ?
Yes.
Unfortunately I won't have time to review them until
Brad King wrote:
On 01/03/2013 10:26 AM, Stephen Kelly wrote:
Currently the new Qt4Targets test I wrote is running on many linux and
mac, but is failing on the SLED LSB platforms.
http://open.cdash.org/testSummary.php?project=1name=Qt4Targetsdate=2013-01-03
Relevant output for reference
Brad King wrote:
On 01/04/2013 12:09 PM, Stephen Kelly wrote:
Brad King wrote:
Yes, please. Thanks for splitting this out.
Done, thanks,
Thanks for cleaning up the dashboard trouble. I've merged this
to master!
Great, thanks!
I've pushed two new branches to my gitorious clone
Brad King wrote:
Steve,
I've reviewed this topic:
4cf80cc Make sure types match exacty without conversion when making
std::pairs. 786aa36 Fix (hopefully) the Mac build.
9bb1f54 Populate the LINK_LIBRARIES property when linking to targets.
1381d56 Add a HEAD-target to target linking
Brad King wrote:
On 01/07/2013 02:50 PM, Stephen Kelly wrote:
I've pushed two new branches to my gitorious clone.
include-dirs-convenience
For the same reason that CMAKE_INCLUDE_CURRENT_DIR exists, but for
interfaces. Please let me know what you think about the idea and API
Clinton Stimpson wrote:
On Monday, January 07, 2013 08:55:40 PM Stephen Kelly wrote:
Stephen Kelly wrote:
Brad King wrote:
On 01/04/2013 12:09 PM, Stephen Kelly wrote:
Brad King wrote:
Yes, please. Thanks for splitting this out.
Done, thanks,
Thanks for cleaning up
Brad King wrote:
On 01/07/2013 03:36 PM, Stephen Kelly wrote:
Perhaps it should be
install(TARGETS testLibRequired
EXPORT RequiredExp DESTINATION lib
INTERFACE_INCLUDES
/foo/bar
)
?
That looks better, but I think it is best to wait until we gain more
Brad King wrote:
On 01/07/2013 06:54 PM, Stephen Kelly wrote:
It's not clear how to add the
commands without bootstrapping them.
In my branch, the BootstrapTest fails:
Add the commands to cmCommands.cxx rather than cmBootstrapCommands.cxx
and do not list them as sources
Brad King wrote:
Steve,
While reviewing this topic I ran the ExportImport test to look for
generator expressions in a link interface property. I do not see
any. The test C++ code appears to verify that libraries are linked
but it is compiled into a static library as added by this commit:
Stephen Kelly wrote:
so it seems that the libraries are being passed to the linker, but the
symbols are not being resolved? I haven't yet seen why that is. Any ideas?
The problem was that I was creating a CXX executable without using extern
C. I've pushed a branch to fix it, but haven't
Brad King wrote:
On 01/10/2013 11:17 AM, Stephen Kelly wrote:
The problem was that I was creating a CXX executable without using extern
C. I've pushed a branch to fix it, but haven't merged it to next yet.
Will I do so?
Yes, please. Then rebase the link interface topic on it so the test
Now that the INTERFACE_PIC branch is in, the next topic I have in that line
is the compatible-INTERFACE-user-properties topic I've just pushed to
gitorious.
Because I'll be automatically linking the Qt4::qtmain library into
executables which are WIN32_EXECUTABLEs, and because QtActiveX
Brad King wrote:
On 01/10/2013 01:04 PM, Stephen Kelly wrote:
the COMPATIBLE_INTERFACE_BOOL property:
set_property(TARGET Qt4::QAxServer APPEND PROPERTY
COMPATIBLE_INTERFACE_BOOL QT4_NO_LINK_QTMAIN)
A better name may be INTERFACE_COMPATIBLE_BOOL since the compatibility
Stephen Kelly wrote:
Brad King wrote:
On 01/10/2013 01:04 PM, Stephen Kelly wrote:
the COMPATIBLE_INTERFACE_BOOL property:
set_property(TARGET Qt4::QAxServer APPEND PROPERTY
COMPATIBLE_INTERFACE_BOOL QT4_NO_LINK_QTMAIN)
A better name may be INTERFACE_COMPATIBLE_BOOL since
Brad King wrote:
On 01/10/2013 12:20 PM, Stephen Kelly wrote:
Looks like I broke it. I was sure I tested it before pushing. Maybe too
much merging and rebasing going on for me. Looking into it now.
Okay, the latest topic head works well:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff
Hi,
Thanks for all the recent merges. We've reached the point where I only have
a handful of topics left.
I've just pushed qt4-autolink-qtmain to my gitorious clone
https://gitorious.org/~steveire/cmake/steveires-
cmake/commit/020b692e7becdc82eb68484abfa3069029b0c8b1
Brad King wrote:
I think we need C++-side help for this. The policy setting should
be recorded when the target to be linked is created. That recorded
setting should be used when evaluating the link interface. Perhaps
we need a generator expression like
$TARGET_POLICY:CMP0020
which
Now that almost everything I've been working on is in master, I've rebased
the rest of the branches to master and pushed them to my clone. They're all
independent now.
* INTERFACE_LIBRARY-target-type
Adding an INTERFACE_LIBRARY type to cmake. This is needed for things like
header-only
Brad King wrote:
On 01/08/2013 09:07 AM, Stephen Kelly wrote:
Done now, thanks.
Currently target_include_directories cannot be used with a RHS target
that has not yet been created. This could be problematic for projects
that want circular include dependencies, especially with targets
Brad King wrote:
On 01/16/2013 12:15 PM, Stephen Kelly wrote:
Good point. I've updated the topic on my gitorious clone, and tested that
it works on Windows. (It required a small fix to a previous topic too).
Thanks. In this expression:
+
$$AND:${_isExe},${_isWin32},${_isPolicyNEW
Brad King wrote:
On 01/16/2013 12:36 PM, Stephen Kelly wrote:
* INTERFACE_LIBRARY-target-type
Adding an INTERFACE_LIBRARY type to cmake. This is needed for things like
header-only libraries. Needs to touch other generators to handle the new
type.
I think this one should go in 2.8.11
Stephen Kelly wrote:
Yes, but older compilers e.g. VS6 will not properly handle function
templates where the template type does not appear in the argument list.
You can work around it by adding a T*=0 argument at the end. Also
this will need test cases.
Ok, thanks, I'll look into that.
I
Alexander Neundorf wrote:
On Monday 21 January 2013, Stephen Kelly wrote:
Hi,
Currently it is common to set somepackage_VERSION_{MAJOR,MINOR,PATCH} in
a Config.cmake file.
The somepackage_VERSION_{MAJOR,MINOR,PATCH,TWEAK} variables are already
set if parsable from the PACKAGE_VERSION
Alexander Neundorf wrote:
Where do you see a problem with this ?
Only that I think it's odd.
The Foo package name is 4.3.2, but if you check all the components, it
looks like 4.3.2.0, which is not 'true'.
Is VERSION_COUNT then actually set to 3 or 4 ?
It is set correctly to 3, but
Hi,
I have this pending patch:
https://codereview.qt-project.org/#change,44532
Given
find_package(Qt5 COMPONENTS Widgets
OPTIONAL_COMPONENTS Svg Quick
)
message(Qt5_FOUND: ${Qt5_FOUND})
message(Qt5Gui_FOUND: ${Qt5Gui_FOUND})
message(Qt5Widgets_FOUND:
Stephen Kelly wrote:
Hi,
I have this pending patch:
Please ignore this one. Sent too early.
--
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
Alexander Neundorf wrote:
On Monday 21 January 2013, Stephen Kelly wrote:
I didn't closely follow the threads around this. Is there any other
behavior that I should account for here?
Seems ok.
Minor nitpick:
I would probably prefer an error message which mentions component
Stephen Kelly wrote:
Alexander Neundorf wrote:
On Monday 21 January 2013, Stephen Kelly wrote:
I didn't closely follow the threads around this. Is there any other
behavior that I should account for here?
Seems ok.
Minor nitpick:
I would probably prefer an error message which
Alexander Neundorf wrote:
I think this is all a mess for cmake's config files, as long as they try
to be relocatable.
Should we just forget about relocatable Config.cmake files on UNIX
(excluding OSX) systems ?
Maybe it would be better to build some awareness into CMake of which
platforms
Alexander Neundorf wrote:
I think in the umbrella config file you can still print something if you
want to, can't you ?
True. I've updated the patch to that now.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Hi there,
I noticed a few hours ago that the Qt4Targets test was failing on Windows
(and has been for a few days). I didn't have time to fix it until now.
It was caused by:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=db3adfc0cbed03ae18361c8bb5ec3be89d6c089b
which was then squashed
Hi there,
I've just pushed tid-system-argument to my clone. It doesn't include unit
tests yet, but I wonder if I can get it into 2.8.11?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep
Stephen Kelly wrote:
Stephen Kelly wrote:
Yes, but older compilers e.g. VS6 will not properly handle function
templates where the template type does not appear in the argument list.
You can work around it by adding a T*=0 argument at the end. Also
this will need test cases.
Ok, thanks
Hi there,
I've pushed the tll-includes-defines topic to my clone again, rebased to
master.
It allows the removal a lot of redundant use of target_include_directories
and target_compile_definitions. I think the real value of the whole feature
will only come when all usage requirements can be
Stephen Kelly wrote:
Hi there,
I've just pushed tid-system-argument to my clone. It doesn't include unit
tests yet, but I wonder if I can get it into 2.8.11?
I looked into this a bit. The way SYSTEM include directories are marked is
makefile-local, not target-local.
That means
Alexander Neundorf wrote:
The CONFIGURE_PACKAGE_CONFIG_FILE() macro could check its
INSTALL_DESTINATION argument, whether it is /lib[64]/ or /usr/lib[64]/
and use full paths in that case.
I'll play around a bit with the macro.
There is now the PackageConfigHelper_UsrMove branch on stage.
Brad King wrote:
On 01/08/2013 09:07 AM, Stephen Kelly wrote:
Done now, thanks.
Currently target_include_directories cannot be used with a RHS target
that has not yet been created. This could be problematic for projects
that want circular include dependencies, especially with targets
Brad King wrote:
I've longed for usage requirements for years and always pictured
them propagating through linking. The huge threads of discussion
earlier made usage requirements seem more complicated than they are
and made it feel like we should hide it all behind new interfaces.
Now I
Stephen Kelly wrote:
INSTALL(EXPORT fooTargets NAMESPACE Foo:: ...)
INSTALL(EXPORT fooTargets EXPORT_INCLUDE_INTERFACE NAMESPACE FooNew:: ...)
or some other naming change, and include() both in the config file.
(2) is easy for us and for upstream, but source incompatible for
downstream
Alexander Neundorf wrote:
Hi,
the docs for the new target_include_directories() say that it accepts only
absolute paths.
Why is that so ?
include_directories() (and also link_directories(), see CMP0015) both
accept relative paths and interpret them as relative to
Alexander Neundorf wrote:
Is there a reason why
target_include_directories() should behave differently ?
That results from the semantics of the INCLUDE_DIRECTORIES property and
http://public.kitware.com/Bug/view.php?id=13188
Ok.
This applies to setting the target property directly.
Alexander Neundorf wrote:
Does
function(target_use_stuff _target )
target_compile_definitions(${_target} ${ARGN})
target_include_directories(${_target} ${ARGN})
target_link_libraries(${_target} ${ARGN})
endfunction()
actually differ from what you want to do for tll() ?
Yes.
Alexander Neundorf wrote:
On Wednesday 16 January 2013, Stephen Kelly wrote:
Brad King wrote:
On 01/08/2013 09:07 AM, Stephen Kelly wrote:
Done now, thanks.
Currently target_include_directories cannot be used with a RHS target
that has not yet been created. This could be problematic
Alexander Neundorf wrote:
On Sunday 27 January 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
Is there a reason why
target_include_directories() should behave differently ?
That results from the semantics of the INCLUDE_DIRECTORIES property
and http://public.kitware.com/Bug
Alexander Neundorf wrote:
On Friday 25 January 2013, Brad King wrote:
On 01/25/2013 03:24 PM, Alexander Neundorf wrote:
On Friday 25 January 2013, Brad King wrote:
On 01/25/2013 05:14 AM, Stephen Kelly wrote:
Are INSTALL(EXPORT)ed files affected at all by this? Do they need
Brad King wrote:
On 01/26/2013 06:57 AM, Stephen Kelly wrote:
Brad King wrote:
How can a package author allow old dependents using the old style to
keep working while also allowing new dependents using the new style
to work?
So, the options I see are:
1) Upstream introduces
Brad King wrote:
On 01/28/2013 12:27 PM, Stephen Kelly wrote:
Yes. However code like this would be ambiguous until generate-time:
target_include_directories(foo PRIVATE bar)
Is bar a target or a directory? That means storing a longer string for
bar:
Simply saying that an existing
Brad King wrote:
On 01/28/2013 02:30 PM, Brad King wrote:
Can we consider using syntax to make this unambiguous?
What's missing is a concise syntax to say that a string *is* a target.
One could write
$TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS
but that exposes the plumbing.
Brad King wrote:
On 01/29/2013 03:53 AM, Stephen Kelly wrote:
This INTERFACE_INCLUDE_DIRECTORIES case is not going to be the only time
an upstream will want to add to its interface. In theory, any time they
want to add a directory to the INTERFACE_INCLUDE_DIRECTORIES they would
have to bump
Brad King wrote:
On 01/29/2013 04:23 AM, Stephen Kelly wrote:
that tll() will handle linking completely and partly setting up the
includes.
I'm not sure what you mean by 'partly'.
I think Alex meant that plain directories cannot be added with tll for
includes. However, we have
Stephen Kelly wrote:
if(PACKAGE_FIND_VERSION VERSION_LESS 2.3
AND NOT MyPkg_INTERFACES)
set(${PACKAGE_FIND_NAME}_NO_INTERFACES 1)
endif()
include(${CMAKE_CURRENT_LIST_DIR}/upstreamTargets.cmake)
Yes, I'm fine with that too, though it will only affect 'new' interfaces
Brad King wrote:
I've implemented it in the tll-includes-defines branch in my clone. I've
only tested it manually though.
Yes, that looks good. Please add tests covering each case:
I've pushed it again to my clone.
Once the fix-target-property-commands topic is in master, we can rebase
Brad King wrote:
On 01/30/2013 03:15 AM, Stephen Kelly wrote:
Brad King wrote:
I've implemented it in the tll-includes-defines branch in my clone.
I've only tested it manually though.
Yes, that looks good. Please add tests covering each case:
I've pushed it again to my clone.
Once
Brad King wrote:
On 01/30/2013 10:57 AM, Stephen Kelly wrote:
Now that fix-target-property-commands was merged to master, I've rebased
tll-includes-defines to master and your testcase works.
Thanks. However, now it leaks out all non-targets referenced by tll
as giant strings
Brad King wrote:
On 01/30/2013 12:09 PM, Stephen Kelly wrote:
We can document that $TARGET_DEFINED has scope only in the current
project and will be processed away during export. I do not think we
want an upstream interface modifying its behavior based on the mere
presence of an arbitrary
Brad King wrote:
I've made the LINKED generator expression a first-class expression, not
just something to be preprocessed away. I think this addresses much of
the cost concern.
Nice! Here are a few comments:
* I got a warning while building your branch:
Alexander Neundorf wrote:
It looks like you merged your patch to next, but didn't account for this
part. I recommend doing something similar to what you did for the macro
to manipulate the _IMPORT_PREFIX in export files. Wait for my
fix-relocatable- include-dirs topic to be merged first
Brad King wrote:
Meanwhile, I've noticed the test run times on some dashboard machines
have doubled since two weeks ago. Can you please run some timing
tests comparing current 'next' to 2.8.10.2 for some existing projects?
Actually they seem to have doubled overnight when tll-includes-defines
Stephen Kelly wrote:
Brad King wrote:
Meanwhile, I've noticed the test run times on some dashboard machines
have doubled since two weeks ago. Can you please run some timing
tests comparing current 'next' to 2.8.10.2 for some existing projects?
Actually they seem to have doubled overnight
Hi there,
The qt4_use_modules is now mostly obsoleted by tll in CMake 2.8.11. The main
difference is that qt4_use_modules does not require the use of imported
targets.
I think we should deprecate it in favor of using tll() with imported targets
(using the imported targets is independent of
David Cole wrote:
I agree with Marcus. There's no reason to deprecate these (other than
deprecating Qt4 entirely, but not yet) unless there's a significant code
clarity advantage.
I think in the case of the qt4_automoc macro at least, there's some
technical issue with changes in
Hi there,
I've pushed a branch with some addtional fixes for various issues in
generator expressions.
One of the issues relates to depends information in the build dir. I fixed
the situation in the makefile generator by expanding the COMPILE_DEFINITIONS
before writing out the
Brad King wrote:
On 02/06/2013 08:27 PM, Stephen Kelly wrote:
I've pushed a branch with some addtional fixes for various issues in
generator expressions.
Thanks, those all look good. I presume you're finding these by
trying to use the new features for Qt5, KDE, and Boost? How else?
Yes
Brad King wrote:
The full solution is to refactor things enough that a new kind of
try_compile can be implemented. It should push the configuration
process state on a stack, run more CMake code in the isolated state
to add some targets, and then generate the build system for them
directly
Brad King wrote:
The full solution is to refactor things enough that a new kind of
try_compile can be implemented. It should push the configuration
process state on a stack, run more CMake code in the isolated state
to add some targets, and then generate the build system for them
directly
Clinton Stimpson wrote:
This is interesting...
The intent of FindQt4.cmake is to find the Qt installation so it can be
used. But in that bug report, the QT_IMPORTS_DIR variable is being used to
determine the qt_dir/imports directory to install their qml plugins -
which is into
the Qt
Clinton Stimpson wrote:
That said, the reported problem in the bug report, that qmake reports the
path, but cmake does not make it available, seems like something to look
into.
Do you have something in mind when you say it should be looked into?
qmake is reporting a non-existant
Brad King wrote:
On 02/07/2013 01:40 PM, Stephen Kelly wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fecede0d9012f78470778cb049b2ab0231b4dcb7
+ If this variable is enabled, CMake automatically adds for each
shared
+ library target, module target and executable target
Brad King wrote:
On 02/07/2013 04:15 PM, Stephen Kelly wrote:
What about OBJECT_LIBRARYs ? I have no experience with them.
Do you add any interface properties to any object libraries currently?
Nope. The only places where cmake populates interface properties
Brad King wrote:
On 02/07/2013 06:23 PM, Stephen Kelly wrote:
Yes. This is a little inconvenient though. I wonder if we could allow tll
with object libraries? The call would set the includes and defines just
like any other target, and would not have any effect on linking, because
Brad King wrote:
It does make sense to publish INTERFACE_INCLUDE_DIRECTORIES and
INTERFACE_COMPILE_DEFINITIONS on object library targets, but we
do not need to chain to them automatically.
I tried writing a unit test for this, but couldn't see why this would be
useful. Consumers of an
Stephen Kelly wrote:
Do the new tcd() and tid() work for them, at least for the impl
properties (COMPILE_DEFINITIONS and INCLUDE_DIRECTORIES)?
I would expect so. cmTargetPropCommandBase is not restrictive at all on
the types of targets it expects (though maybe it should be... ?). It makes
Brad King wrote:
On 02/08/2013 01:25 PM, Stephen Kelly wrote:
Brad King wrote:
It does make sense to publish INTERFACE_INCLUDE_DIRECTORIES and
INTERFACE_COMPILE_DEFINITIONS on object library targets, but we
do not need to chain to them automatically.
I tried writing a unit test
Brad King wrote:
On 02/08/2013 01:46 PM, Stephen Kelly wrote:
I think it might make sense to handle them particularly in LINKED, but I
notice set_property and set_target_properties also work fine with them
(should that be changed too?)
The ExternalProject module makes heavy use
Brad King wrote:
Currently the code
target_link_libraries(foo $$CONFIG:Debug:not_a_target)
will put a giant generator expression in the include directories
and compile definitions properties and it will be exported, right?
Yes.
I do not like this. Since we decided not to use a new
Brad King wrote:
On 02/07/2013 11:42 AM, Stephen Kelly wrote:
It seems to me it would be much easier and less duplicative to
add a way to specify TARGETS in try_compile, and in cmCoreTryCompile,
generate the IMPORTED targets there with whatever properties they have
Brad King wrote:
On 02/08/2013 04:56 PM, Brad King wrote:
On 02/08/2013 03:16 PM, Stephen Kelly wrote:
My preference currently is to leave things as they are including the
long and useless string.
Your analysis is quite extensive, thanks.
I thought about this more over the weekend. I
Matthew Woehlke wrote:
I've been reading about this feature for a while, and one thing that has
been in the back of my mind is, how will code generation tools (Qt MOC
comes to mind) that depend on being able to get the list of include
directories to pass to a non-compiler executable work when
Brad King wrote:
On 02/09/2013 06:24 AM, Stephen Kelly wrote:
The approach that I took was to not expose the feature through the cmake
language, and instead make the use of CMakeExpandImportedTargets
obsolete, and make try_compile directly handle CMAKE_REQUIRED_LIBRARIES
containing IMPORTED
Alexander Neundorf wrote:
On Monday 11 February 2013, Brad King wrote:
On 02/10/2013 10:14 AM, Alexander Neundorf wrote:
1) either put a check for the required targets in the generated targets
file, and make find_package() fail by setting foo_FOUND to FALSE. This
should be relatively
Alexander Neundorf wrote:
Another thing came to my mind.
Let's say kguiaddons depends on kconfig, so it will do
find_package(kconfig)
I guess it should not search the packages kconfig depends on, but rely on
kconfigConfig.cmake doing that.
Yes.
So far, so good.
Now, if we have some
Alexander Neundorf wrote:
You may also want to cherry-pick 3c84b519260398adef95a0e08f268e93430ccaf9
from my clone to get the policy warning in the cmake language.
so I branch away from master, pick the patch you mention, and then merge
into next, and everything will be fine still for
Brad King wrote:
On 02/11/2013 01:34 PM, Stephen Kelly wrote:
I also considered splitting the targets from the non-targets in the
implementation of the macros. That would mean changing the order of the
content of target_link_libraries calls generated by cmCoreTryCompile
because we would have
Brad King wrote:
On 02/11/2013 02:18 PM, Stephen Kelly wrote:
Would cmCoreTryCompile also generate a target_link_libraries line for the
targets after the existing target_link_libraries line?
Otherwise using the raw try_compile would not do what you expect:
I wouldn't expect TARGETS
601 - 700 of 3503 matches
Mail list logo
