The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14251
==
Reported By:Minmin Gong
Assigned To:
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
On 06/28/2013 06:02 AM, Stephen Kelly wrote:
Is it really worthwhile to introduce both INTERFACE and LINK_INTERFACE?
No, I forgot that LINK_INTERFACE does not exist.
It is fine to just add INTERFACE.
* LINK_PUBLIC is treated as an alias for PUBLIC
* LINK_PRIVATE is treated as an alias for
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.
Thanks,
-Brad
--
Powered by www.kitware.com
Visit other Kitware
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.
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14252
==
Reported By:Mojca Miklavec
Assigned To:
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
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=14254
==
Reported By:Tobias Hieta
Assigned To:
Hi all,
Recently in clang trunk, they added a new warning which we now see on Rogue7
since I updated my clang:
http://open.cdash.org/viewBuildError.php?type=1buildid=2949429
CMake/Source/kwsys/RegularExpression.cxx:347:5: warning: 'register' storage
class specifier is deprecated
Sean McBride wrote:
Hi all,
Recently in clang trunk, they added a new warning which we now see on Rogue7
since I updated my clang:
http://open.cdash.org/viewBuildError.php?type=1buildid=2949429
CMake/Source/kwsys/RegularExpression.cxx:347:5: warning: 'register' storage
class specifier
On 6/28/2013 11:37 AM, Sean McBride wrote:
I can make a patch to remove the 'register' keyword, if you will accept it.
Anyone have a philosophical objection? If so, I will suppress the warning.
We can remove it from our code but for code imported from
third-party projects please suppress it
I see no reason in using the register keyword. Currently compilers
ignore the register keyword, and basically it should be considered
noise when reading.
On Fri, Jun 28, 2013 at 11:37 AM, Sean McBride s...@rogue-research.com wrote:
Hi all,
Recently in clang trunk, they added a new warning
On 2013-06-28 08:40, Brad King wrote:
What about the APPEND mode of export? Do you plan to try to
collect all the appended pieces together, all delayed until
generate time?
That would be great if you could! One of my big gripes with export() is
how much less elegant it is generating a
On 2013-06-28 09:06, Stephen Kelly wrote:
Brad King wrote:
Perhaps the policy could also disallow the
APPEND mode altogether. IIRC I've participated in discussion
in the past about how APPEND is a bad approach anyway.
I've never used it, but then I've never used export() except in unit tests
On 6/28/2013 12:27 PM, Matthew Woehlke wrote:
To me it would make much more sense if export() was more like
install(EXPORT), where one declares at the point of the add_library()
the desire to export a target, which adds to a list the CMake keeps
track of internally in order to generate an
On 6/28/2013 12:49 PM, Brad King wrote:
On 6/28/2013 12:27 PM, Matthew Woehlke wrote:
To me it would make much more sense if export() was more like
install(EXPORT), where one declares at the point of the add_library()
the desire to export a target, which adds to a list the CMake keeps
18 matches
Mail list logo
