Hi,
Last year, the new INTERFACE_LIBRARY target type was to be part of the
'target usage requirements' feature, but it was deferred until after 2.8.11.
It was discussed a bit though, in my point 3 in this thread and some follow
up messages:
Brad King brad.king@... writes:
Steve,
I think this may fall under your expertise now. The goal is to generate
a nice error message when an imported target's link interface depends on
other targets that should have been imported but have not been. Currently
we just get a build-time
Brad King wrote:
For makefile generators and xcode it is not possible to use create
non-imported targets in a buildsystem. On Windows it doesn't seem to be
possible either (the : is mistaken for a drive delimiter). It does
currently work with Ninja though, so a policy may be needed if it's a
Brad King wrote:
On 04/24/2013 08:38 AM, Stephen Kelly wrote:
I pushed a set-sysroot branch implementing this to my clone. This
actually also makes it possible to cross-compile for android without
forcing the compiler.
That looks like a good start. The --sysroot flag should be looked
up
Brad King wrote:
I've pushed the fix-multi-config-tll-include-dirs branch to my clone.
That's a much more detailed explanation, thanks.
Pre-evaluating the expression as Debug regardless of the
configuration involved feels like a hack. Since this all occurs
at generate time already
Brad King brad.king@... writes:
I looked into implementing this and realized that we're not propagating
usage requirements from the entire link closure, only from the direct
dependencies.
Are you sure? Maybe I don't understand what you mean. Can you post a code
snippet?
add_library(foo
Brad King wrote:
On Fri, Apr 26, 2013 at 10:39 AM, Stephen Kelly
steve...@gmail.com wrote:
Brad King brad.king@... writes:
I looked into implementing this and realized that we're not propagating
usage requirements from the entire link closure, only from the direct
dependencies.
Are you
Brad King wrote:
The caching is simplified because we never need to clear it since these
are now only called during generation and never during configuration.
I've looked again at the code, and there is a condition for clearing the
cache if not configuring. I think this is because of export()
Stephen Kelly wrote:
It can probably be refactored to bypass the genex evaluation though.
The refactoring I described can be done in the future I think, but doesn't
really solve the bug anyway, because it is evaluation of the generator
expression for the target itself which is causing
Brad King wrote:
On 04/29/2013 06:29 AM, Stephen Kelly wrote:
I've force-pushed the fix-multi-config-tll-include-dirs branch with a
more- simple fix for this issue to my clone.
Okay, that looks good. Please rebase on the partial fix I merged last
week so we can test it in 'next'. I'll
Brad King wrote:
On 04/30/2013 07:38 PM, Stephen Kelly wrote:
Brad King wrote:
Reading the commit messages and code in more detail, it looks wrong
to have CachedLinkInterfaceIncludeDirectoriesEntries not per-config.
It looks like the generated value can be different per-config and
currently
Brad King wrote:
On 05/02/2013 02:46 AM, Stephen Kelly wrote:
Brad King wrote:
On 04/30/2013 07:38 PM, Stephen Kelly wrote:
I'm saying that even after the current version of the topic the
caching is still accumulating across configurations in multi-config
generators. AFAICT that part
Brad King wrote:
On 04/23/2013 03:26 PM, Stephen Kelly wrote:
The $JOIN branch is almost ready, but I thought something worth
bringing up is the use of a comma as a separator.
[snip]
$JOIN:one;two;three,, # results in one,two,three
Do you think that's more or less confusing? Should I
Brad King wrote:
On 04/23/2013 03:07 PM, Stephen Kelly wrote:
file(EVALUATE ${CMAKE_CURRENT_SOURCE_DIR}/input.txt
${CMAKE_CURRENT_BINARY_DIR}/output.txt
)
[snip]
file(EVALUATE ${CMAKE_CURRENT_BINARY_DIR}/input.txt
${CMAKE_CURRENT_BINARY_DIR}/output_
Brad King wrote:
Having said that, would IMPORTED targets actually be good enough for all
the things you list, maybe with some wrapper macros ?
The IMPORTED targets still need to have an IMPORTED_LOCATION that refers
to a real file, so they are not quite equivalent to the proposed INTERFACE
Brad King wrote:
On 05/02/2013 11:07 AM, Stephen Kelly wrote:
How do you generate a file only once with non-config-dependent content in
a simple case?
file(GENERATE
OUTPUT the_output.txt
CONTENT The content
CONDITION 1
)
That will be generated N times in multi
Brad King wrote:
On 05/02/2013 01:44 PM, Stephen Kelly wrote:
Brad King wrote:
Make it an error if different *content* will be written to the same
file name by different configurations. Generate for all configs into
per-config temp files. Then identify all files that map to a single
name
Brad King wrote:
On 05/02/2013 11:26 AM, Stephen Kelly wrote:
Perhaps we could do aliasing with a target property instead?
add_library(foo SHARED foo.cpp)
set_property(TARGET foo APPEND PROPERTY ALIAS_NAME KF5::foo)
No, I like to be able to say that all logical target names
Hi,
Last year we discussed the addition of a INTERFACE_LINK_LIBRARIES property
to replace the (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_CONFIG)? properties.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5398
After a lot of back-and-forth, I bypassed the issue of that property
Brad King wrote:
On 05/03/2013 07:37 AM, Stephen Kelly wrote:
Alternatively we could decide to finally drop the
INTERFACE_LINK_LIBRARIES property.
I think we can just drop it for now.
I'm not sure what you mean by 'for now'?
I'd prefer not to introduce INTERFACE_LIBRARY with support
Robert Maynard wrote:
The CMake 2.8.11 release candidate continues. This is the last RC
unless a critical, must-fix issue is found. You can find the source
and binaries here:
http://www.cmake.org/files/v2.8/?C=M;O=D
Just a reminder to report issues as soon as you find them, even if you
Brad King wrote:
On 05/06/2013 12:44 PM, Stephen Kelly wrote:
I'm not sure what you mean by 'for now'?
I meant we could drop it and move on but not rule out the possibility
of someday moving to it for consistency and (eventual) simplicity.
I'd prefer not to introduce INTERFACE_LIBRARY
Stephen Kelly wrote:
* When exporting, if 'the implementation is the interface'
Oops, forgot to finish writing this.
With the policy, the required tll signature, and new property, the
implementation is never the interface for shared libraries. Static libraries
are already handled
Brad King wrote:
Currently these topics are open on the stage relating to Qt4/5:
* workaround-usr-move-qt5: I think this can be reverted.
It never fixed the problem on Marcus' machine fully and
I think he upgraded Qt to make the problem go away.
I thought the same. Done.
*
Any idea what is causing this dashboard problem in the continuous tests?
http://open.cdash.org/testDetails.php?test=190528962build=2907105
It works for me...
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Brad King wrote:
On 05/16/2013 03:07 PM, Stephen Kelly wrote:
Any idea what is causing this dashboard problem in the continuous tests?
http://open.cdash.org/testDetails.php?test=190528962build=2907105
It works for me...
You need to enable_language(CXX) before using C++ sources
Hi,
I've pushed the language-generator-expressions branch to my clone, and the
target-COMPILE_OPTIONS branch which depends on it, which should be the
implementation of
http://public.kitware.com/Bug/view.php?id=6493
I hit a problem with the xcode and visual studio generators in that the
Hi,
I run Qt unit tests like this:
qmake make check
The make check target runs cmake and ctest. However, this does not take
advantage of the ability of CTest to run tests in parallel. Rather than
trying to shoehorn in a -j argument via the qmake files, I'd prefer to set a
CTEST_TESTFLAGS
Brad King wrote:
On 05/16/2013 04:43 PM, Stephen Kelly wrote:
I've pushed the language-generator-expressions branch to my clone, and
the target-COMPILE_OPTIONS branch which depends on it, which should be
the implementation of
http://public.kitware.com/Bug/view.php?id=6493
I hit
Brad King wrote:
On 05/16/2013 04:56 PM, Stephen Kelly wrote:
I run Qt unit tests like this:
qmake make check
The make check target runs cmake and ctest. However, this does not take
advantage of the ability of CTest to run tests in parallel. Rather than
trying to shoehorn in a -j
Brad King wrote:
Can I merge that one to next?
Please first clean up the failures currently caused by topics already
in next and wait for a clean dashboard before adding more topics.
In particular it looks like there is a problem with bootstrap.
Yes, I fixed that one earlier.
Hi,
Yesterday in the continuous dashboards, several windows machines started
failing with this test in a way that does not make sense:
http://open.cdash.org/testDetails.php?test=190556209build=2907224
The issue was resolved after I reverted the add-EXPORT_NAME topic.
I've re-added part of
Brad King wrote:
On 05/17/2013 11:43 AM, Stephen Kelly wrote:
Yesterday in the continuous dashboards, several windows machines started
failing with this test in a way that does not make sense:
http://open.cdash.org/testDetails.php?test=190556209build=2907224
The issue was resolved after
Brad King wrote:
We already gloss over the difference between CMAKE_C_FLAGS and
CMAKE_CXX_FLAGS in the IDE generators by using the one corresponding
to the target link language IIRC.
Ok, so the options are
A) Document that COMPILE_LANGUAGE is actaully the link language in the case
of the
Hi,
I've pushed a VISIBILITY_DEFAULT-property topic to my clone. It adds a
VISIBILITY_DEFAULT target property which works similar to the
POSITION_INDEPENDENT_CODE property, and is intended to replace the try-
compiles in GenerateExportHeader.
I assume I can't simply move the try-compiles to
Hi,
I've pushed the EXPORT_NAME-genex topic to my clone. It allows
uniform/generic renaming of targets on export. That means that while
buildsystem targets might be named boost_any/boost_mpl, they can be exported
as boost::any/boost::mpl like this:
set(CMAKE_EXPORT_NAME
Alexander Neundorf wrote:
Having LINK_INTERFACE_LIBRARIES and INTERFACE_LINK_LIBRARIES will make it
hard to remember which one is the deprecated one and which one is the
recommended one.
I recommend INTERFACE_LINK_LIBRARIES for the property name (for consistency
with the other new
Brad King wrote:
On 05/18/2013 06:18 AM, Stephen Kelly wrote:
I've pushed a VISIBILITY_DEFAULT-property topic to my clone. It adds a
VISIBILITY_DEFAULT target property which works similar to the
POSITION_INDEPENDENT_CODE property, and is intended to replace the try-
compiles
Brad King wrote:
What's so bad about the exported targets being called boost_...
instead of boost::...?
A stronger indication that it is an imported target. boost::... can only be
an imported target, but boost_... could be an imported target, a in-build
target or a library.
As we
Brad King wrote:
On 05/20/2013 09:42 AM, Stephen Kelly wrote:
set(CMAKE_DEFAULT_VISIBILITY hidden)
add_library(foo ...)
add_library(bar ...)
add_library(bat ...)
set_property(TARGET bat PROPERTY DEFAULT_VISIBILITY default)
I know this is only a bit nicer. It's an idea worth
Brad King wrote:
On 05/20/2013 09:48 AM, Stephen Kelly wrote:
Brad King wrote:
What's so bad about the exported targets being called boost_...
instead of boost::...?
A stronger indication that it is an imported target. boost::... can only
be an imported target, but boost_... could
Stephen Kelly wrote:
if (NOT CMAKE_${lang}_COMPILE_OPTIONS_VISIBILITY)
There is also this by the way:
http://docs.oracle.com/cd/E19205-01/819-5267/bkbda/index.html
Does Sun CC supports both -xldscope=hidden and -fvisibility=hidden?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit
Alexander Neundorf wrote:
the value and cost.
value:
* We can assume that NS::foo is an imported target and error if not
found
Since it was never forbidden and not even officially recommended to use
:: when exporting targets, I'm not sure the :: should be used for the
decision
Stephen Kelly steveire@... writes:
On 4/10/2013 11:54 AM, Stephen Kelly wrote:
(at the very bottom)
http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_00894/win64-msvc2012_developer-build_qtnamespace_Windows_8/log.txt.gz
Any ideas?
I think you want this generator
Stephen Kelly wrote:
Stephen Kelly steveire@... writes:
On 4/10/2013 11:54 AM, Stephen Kelly wrote:
(at the very bottom)
http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_00894/win64-msvc2012_developer-build_qtnamespace_Windows_8/log.txt.gz
Any ideas?
I think you
Brad King wrote:
Stephen,
We reviewed most of your latest topics in 'next' today, merged
many to 'master', and committed trivial fixups to a couple.
However, there are problems with some topics:
* genex-generate-file: Appears to leak memory. It calls
new
Alexander Neundorf wrote
So, I don't think we should pretent they don't exist, or try to hide the
fact that they exist.
How is this related to using the target names directly ?
If he really wants the location of the binary, he needs to use
get_target_property(loc Qt4::QtUiTools
Brad King wrote:
I'm fine with the :: convention for those who want it but it should
not be the only recommended way.
IMPORTED targets can't be used as the RHS in tll, for example.
Huh? That is *the* use case for them.
Alex is right. I meant lhs.
Thanks,
Steve.
--
Powered by
I pushed a PRESET_VISIBILITY-property to my clone.
Stephen Kelly wrote:
Thanks for the explanation. (I assume you meant
s/DEFAULT_VISIBILITY/VISIBILITY_DEFAULT/ in your example.)
Yes. I've been backward and forward over what to call that property while
implementing it.
I settled
Brad King wrote:
On 05/23/2013 06:58 AM, Stephen Kelly wrote:
I settled on PRESET_VISIBILITY because it does not have the word default
in it, which avoids. I don't want to bikeshed the name, so if you chose
something you'd prefer, I don't mind changing it.
I like PRESET but I prefer
Brad King wrote:
On 05/22/2013 06:12 PM, Stephen Kelly wrote:
Brad King wrote:
I'm not sure what caused that failure, but according to local testing
on my VS 6 the failure we now see is caused by (according to git bisect)
the language-generator-expressions topic. I've merged join-genex
Brad King wrote:
On 05/22/2013 04:37 AM, Stephen Kelly wrote:
Brad King wrote:
* genex-generate-file: Appears to leak memory. It calls
new cmGeneratorExpressionEvaluationFile but has no delete.
Thanks, fixed.
The topic looks clean now, but it does not add any documentation
Brad King wrote:
On 05/23/2013 09:25 AM, Brad King wrote:
On 05/22/2013 06:12 PM, Stephen Kelly wrote:
Brad King wrote:
I'm not sure what caused that failure, but according to local testing
on my VS 6 the failure we now see is caused by (according to git
bisect)
the language-generator
Alexander Neundorf wrote:
Beside that, it still leaves the issue that the only existing standard
for find_package() is the names of the variables:
find_package(Foo)
include_libraries(${Foo_INCLUDE_DIRS})
...
target_link_libraries(hello ${Foo_LIBRARIES})
Following that would be a
Hi,
I pushed suppress-unused-cli-with-value-in-cache to my clone. It was failing
dashboard tests last week because, I think, ctest runs on dirty build dirs
in the continuous tests.
As a solution I added the CMakeCache.txt to ADDITIONAL_MAKE_CLEAN_FILES,
which works fine with the Makefile
Brad King wrote:
On 05/10/2013 06:41 AM, Stephen Kelly wrote:
* http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5680
(New INTERFACE_LINK_LIBRARIES policy approach)
I remember being quite happy with the proposal I made at the start of
that thread. Let's see if we can
Brad King wrote:
Steve,
I think we're pretty close to agreement here!
On 05/30/2013 05:31 AM, Stephen Kelly wrote:
This will give projects a choice on whether they want to populate the
old properties explicitly or ask CMake to do it for them.
Rather than offer so much choice
Rolf Eike Beer wrote:
https://bugs.gentoo.org/show_bug.cgi?id=465930
I have no clue about this, is that a Gentoo problem or one of CMake?
I don't have that problem, I'm just relaying it upstream.
I can't explain it either. The Qt5Widgets_EXECUTABLE_COMPILE_FLAGS variable
in
Hi,
I've pushed a qt4-macros-TARGET-arg branch to next. It refactors the Qt 4
moc related macros to process a TARGET argument. The target is used as the
source of include directories, which are then passed to moc as -I arguments.
Previously, those macros read the INCLUDE_DIRECTORIES directory
Hi there,
While most of the new features I've been writing have been about moving away
from directory-scoped commands towards target scoped commands, one command
which I think still makes sense as a directory scoped command would be a
command for setting compile options. Currently warnings
Brad King wrote:
On 05/28/2013 02:39 PM, Stephen Kelly wrote:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=31084c207d23c98f85f160ab98e37ff8a705818c
CLI: Suppress the unused warning if the key value pair is cached.
[snip]
---build-noclean
The removal of this option means
Brad King wrote:
Stephen,
On 06/04/2013 10:49 AM, Mantis Bug Tracker wrote:
http://www.cmake.org/Bug/view.php?id=14201
==
Summary:FindCUDA does not forward include directories
assigned by
Hi,
I've pushed my current work to my clone in the INTERFACE_LINK_LIBRARIES-prop
topic. It's not yet complete, but I think it has almost all elements of the
solution.
Brad King wrote:
I wonder if we can distinguish PUBLIC/PRIVATE/INTERFACE for STATIC
for application of usage requirements.
James Bigler wrote:
Things get dicey when you want to pass things like include directories as
arguments. There are quotes to deal with as well as maximum argument
length issues. I'm not saying it can't be done, but it needs to be done
*carefully*.
Yes. I just pushed a proof-of-concept for
I've force pushed to my clone again. I haven't added tests yet, and I've
only been smoke testing as I go along.
Brad King wrote:
In the tll() signature policy I think LINK_PUBLIC/LINK_PRIVATE should
be an alias for PUBLIC/PRIVATE. The old signatures are only the
one without any keywords
Brad King wrote:
On 06/03/2013 04:09 AM, Stephen Kelly wrote:
I've pushed a qt4-macros-TARGET-arg branch to next. It refactors the Qt 4
moc related macros to process a TARGET argument. The target is used as
the source of include directories, which are then passed to moc as -I
arguments
Hi,
This was discussed here before:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6255/focus=6273
I don't think the idea to have quotedness determine whether
add_custom_command expands a list into multiple arguments or consider it one
argument is a good one.
Instead, I
Brad King wrote:
On 06/05/2013 10:11 AM, Stephen Kelly wrote:
I don't think the idea to have quotedness determine whether
add_custom_command expands a list into multiple arguments or consider it
one argument is a good one.
Can you present an argument for why it is not a good idea?
As far
Brad King wrote:
Once we have agreement on that then PUBLIC|PRIVATE|INTERFACE will be
aliases.
Ok, I've updated the topic in my clone. I think the only remaining issue is
new tests for tll().
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Brad King wrote:
Instead let's consider introducing a usage requirement that can bring
in object libraries, external objects, or even source files. That
would solve this and be pretty cool too.
There's no existing API for manipulating the source items of a target after
its creation, so I
Hi,
As I wrote in
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7082
(Linking to OBJECT libraries?, 2013-06-06)
I was experimenting with adding a static library to the INTERFACE of the
Qt5::Gui target. While that seemed to work, the target build order is not
correctly
Brad King wrote:
(2) Name the property SOURCES and allow projects to edit it.
Having access to the list of sources for both reading and writing
has been requested occasionally. It is not safe to edit after
reading the LOCATION property or something else that computes
the linker language, but
Brad King wrote:
The tll signature commit does not do what I had in mind.
Ok, I'll have another look later. Meanwhile, I've merged the first
orthogonal commits to next to see what the dashboard makes of it.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source
Brad King wrote:
On 06/06/2013 02:18 PM, Stephen Kelly wrote:
Brad King wrote:
But those are incomplete. The policy CMP0022 you added should also
affect the implementation of tll to choose which interface properties
to populate.
I thought that's what we have a second policy (CMP0023
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
Brad King wrote:
On 06/06/2013 11:15 AM, Stephen Kelly wrote:
Also it may be tricky due to the way $TARGET_SOURCES:... 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
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
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
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
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
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
Brad King wrote:
On 06/07/2013 09:13 AM, Stephen Kelly wrote:
SOURCES $$CONFIG:Debug:other.cpp
That has been requested as a feature occasionally. I'm not sure
it is possible to implement on all the generators though.
Ok. I won't have generator expressions in SOURCES as a goal, but I'll
Robert Maynard wrote:
@@ -666,7 +666,7 @@ public:
*/
const std::vectorstd::string GetOutputFiles() const
{ return this-OutputFiles; }
- void AddCMakeOutputFile(const char* file)
+ void AddCMakeOutputFile(const std::string file)
It makes sense to split this into a separate patch.
Thanks,
Hi there,
The ExportImport test is failing with two Xcode dashboards (but not the
other xcode dashboards)
http://open.cdash.org/testSummary.php?project=1name=ExportImportdate=2013-06-25
http://open.cdash.org/testDetails.php?test=196266835build=2946532
clang: error: no such file or
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
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=1name=ExportImportdate=2013-06-25
http://open.cdash.org/testDetails.php?test=196266835build=2946532
clang
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
Brad King wrote:
On 06/26/2013 11:16 AM, Stephen Kelly wrote:
http://open.cdash.org/testDetails.php?test=196514636build=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
Brad King wrote:
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.
I did
Brad King wrote:
On 06/27/2013 05:28 AM, Stephen Kelly wrote:
Please post a snippet of cmake code showing the problems you are seeing
so that I can easily understand them.
Consider this code using CMake 2.8.11:
cmake_minimum_required(VERSION 2.8.11)
#...
add_library(foo SHARED foo.c
Brad King wrote:
though it may be sporadic.
One dashboard that passed after I changed it to use a SHARED library now
fails again.
http://open.cdash.org/buildSummary.php?buildid=2948465
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Brad King wrote:
Steve,
On 6/27/2013 10:34 AM, Brad King wrote:
Okay, this problem is a bit deeper than I thought.
I'm working on a topic to resolve it.
For now I reverted the compiler-version-genex topic to make room.
I will try to get my topic ready today.
I've merged a
Brad King wrote:
On 6/27/2013 10:18 AM, Stephen Kelly wrote:
I went with the option of setting the INTERFACE_LINK_LIBRARIES
unconditionally in tll.
That's fine with me. It keeps things simpler internally.
Strictly speaking we should make it conditional on the
policy not being set to OLD
Brad King wrote:
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):
Hi,
I've pushed an export-policy topic to my clone which attempts to disallow
including the result of the export command. This is part of making it
possible to make export() be executed at generate time in the future.
There are limitations to my topic already. For example, it doesn't warn if
Brad King wrote:
So, if the first argument after the lhs is LINK_PUBLIC
or LINK_PRIVATE then it is the existing signature, and if
it is PUBLIC or PRIVATE or INTERFACE then it is the
new signature, right?
Right. That's almost what is in my tll-new-signatures branch:
Brad King wrote:
Steve,
Please take a look at this failure:
http://open.cdash.org/testDetails.php?test=196577461build=2949683
expanded command line '...' too long
I think the GeneratorExpression test needs to be split into
even more parts.
Yep, that was expected eventually.
Brad King wrote:
I believe
tll(tgt LINK_PRIVATE a LINK_PUBLIC b LINK_PRIVATE c)
is valid today. I can't think of a reason to want that
We considered such cases way back when first discussing that interface.
The use case is that there is an ordered implementation dependency on
a;b;c
Brad King wrote:
On 06/27/2013 03:57 PM, Sean McBride wrote:
So I opened the .xcodeproj with Xcode.app and I don't see any
excludedFromAll item in the 'scheme' popup. Do you?
In Xcode 4.5.2 on OS X 10.8 the test passes for me and I do
see excludedFromAll in the list of targets in the GUI.
Brad King wrote:
On 07/01/2013 09:17 AM, Stephen Kelly wrote:
However, a colleage tested it (I have no Mac to hand), and told me that
if those relevant lines are removed from the Config files, CMake does not
seem to pass the relevant -F and --framework lines to the compiler, so
#includes do
801 - 900 of 3503 matches
Mail list logo
