Brad King wrote:
Steve,
Thanks for working on this. Please update the documentation
of tll() to mention this behavior.
Also, the use of CollapseFullPath to evaluate /.. seems more
complicated than necessary. A single CollapseFullPath of the
original input followed by a check against a
Hi there,
compile-defs-debugging is failing with some Visual Studio generators. I
don't have those ides to figure out what is going wrong. My reading of the
Preprocessor test indicates that if my new test fails, that one should too,
so I don't understand where the problem is.
The
clin...@elemtech.com wrote:
The framework-interface-includes test is also failing on all macs, after
I changed it to use a regex to match a framework. I don't have ready
access to a mac for a few days to find out what is wrong there.
I've pushed a fix for you on
Rolf Eike Beer wrote:
Ok, I've pushed an updated version to the rework branch. A test for the
component check is missing, but all of your other suggestions should have
been addressed.
Has anyone anything else, otherwise I will o and put this into CMake next
once I have the test.
Do you
Nicolas Desprès wrote:
Hi Stephen,
Did you have any chance to look at the code? I would love to see it
integrated in the next release. That being said, there is no pressure.
I'll have a look now.
+UpdateOutputToSourceMap(outputs, file);
is missing a 'this-', as per the style.
Nicolas Desprès wrote:
+UpdateOutputToSourceMap(outputs, file);
is missing a 'this-', as per the style. There's a couple of repeats of
that.
Done
You seem to have missed this one.
There are also other style issues.
* Don't put an else after a return
* Wrap single line blocks in {}
Nicolas Desprès wrote:
That's said we can optimize further as I mentioned in my comment (
https://github.com/nicolasdespres/CMake/commit/59c871da8b00554812e93ba9c6e47d864424efb0#L0R2023
).
Do you have an opinion about it?
Do I understand correctly that the issue is that OutputToSource
Hi there,
I've pushed a cpack-bar-package topic to my clone
https://gitorious.org/~steveire/cmake/steveires-cmake
It is the start of a CPack generator for BlackBerry BAR packages, required
for deployment to those devices. I haven't worked much with CPack before, so
I'd appreciate some
Hi,
In response to
https://bugreports.qt-project.org/browse/QTBUG-32599
I first considered adding something like
if(NOT QT_INCLUDE_DIRS_NO_SYSTEM)
set_property(TARGET Qt5::Core
SYSTEM_INTERFACE_INCLUDE_DIRECTORIES
${Qt5Core_INCLUDE_DIRS}
)
endif()
for each imported
Hi,
Commit 342fc0401005 (Recognize shared library files with a numerical suffix,
2013-04-11) resulted from
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6613/focus=6616
In a more-recent review, I thought that if there is an extension in the exts
list which already has
Brad King wrote:
On 07/25/2013 09:16 AM, Stephen Kelly wrote:
target_link_libraries(foo SYSTEM Qt5::Core)
That looks okay to me so long as SYSTEM must always be the first keyword.
Yes, that's how I've implemented it currently.
We could also consider adding it only to the modern (newest
Matthew Woehlke wrote:
On 2013-07-25 11:25, Stephen Kelly wrote:
Brad King wrote:
On 07/25/2013 09:16 AM, Stephen Kelly wrote:
Should we treat the INTERFACE_INCLUDE_DIRECTORIES of all IMPORTED
targets as SYSTEM includes automatically?
I don't think so because one could be importing targets
Matthew Woehlke wrote:
On 2013-07-25 13:25, Stephen Kelly wrote:
Brad King wrote:
On 07/25/2013 12:22 PM, Stephen Kelly wrote:
library A should have a unit test which attempts to compile all
of its headers with all warnings enabled. In Qt every module has a
'headersclean' unit test which
Nicolas Desprès wrote:
Hi Stephen,
I think I need your insight of CMake code base here. According to my tests
(ie ExportImport and CustomCommand), GetSourceFileWithOutput() is called
with a relative path only from here:
https://github.com/Kitware/CMake/blob/master/Source/cmTarget.cxx#L1939
Brad King wrote:
On 07/25/2013 01:25 PM, Stephen Kelly wrote:
Either way, the tll() SYSTEM option could still be useful.
I'll add that tomorrow.
Can we wait until after 2.8.12 to add this? We're already adding
the new tll signature and policy CMP0023. I'd like to avoid
confusion
Brad King wrote:
Perhaps
bool LinkLanguagePropagatesToDependents() const
{ return this-TargetTypeValue == STATIC_LIBRARY; }
I think this one is fine. I've re-pushed the commit to the minor-cleanups
topic.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to patch
it properly and the benchmark are the same whether we use the default
comparison functor or mine.
So I think you can merge it like that. I have pushed a new version without
the comment.
I
Nicolas Desprès wrote:
On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
steve...@gmail.com wrote:
Nicolas Desprès wrote:
It was fastest because it was not doing the right thing. I tried to
patch it properly and the benchmark are the same whether we use the
default comparison functor
Nicolas Desprès wrote:
Also, I don't see why the custom comparison functor is needed at all. I
removed it and sped up the test significantly. Can you explain?
I had some failing tests because the previous algorithm was not a plain
strcpy().
I don't see any strcpy(). Anyway, I think that's
Alexander Neundorf wrote:
So it can be used in tll() calls to link against the library (package).
What makes it differ from Foo_LIBRARIES, is that CMake checks that each of
the items listed in this variable
* is an existing target
* has the INTERFACE_INCLUDE_DIRS property set.
Are you
Brad King wrote:
Steve,
On 07/26/2013 04:43 AM, Mantis Bug Tracker wrote:
http://www.cmake.org/Bug/view.php?id=14317
What do you think about adding generator expressions to install
DESTINATION options. In particular the $CONFIGURATION genex
would be useful in this case.
Yes,
Hi,
It's now possible to invoke cmake with -DCMAKE_WARN_DEPRECATED=1 and also
with -DCMAKE_ERROR_DEPRECATED=1 to get deprecation warnings or errors.
I wonder if we should add --deprecated-warnings and --deprecated-errors and
document them in cmake --help, as --warn-uninitialized etc? I think
Brad King wrote:
-Wdeprecated
-Wdeprecated=error
-Wuninitialized
Ok, I'll come back to that after 2.8.12.
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
Brad King wrote:
On 07/29/2013 06:57 PM, Stephen Kelly wrote:
Yes, $CONFIGURATION should work both before and after export.
So the question is how to know whether to evaluate it during
export or write it literally in the file. In this case we want
to expand it during export because we
Alexander Neundorf wrote:
Comments ?
If possible, I'd like to get that into 2.8.12.
Note that even in KDE there isn't consensus on whether to rely on this in
the non-short term:
http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80241
I don't see any particular reason to get it
Brad King wrote:
On 07/30/2013 09:46 AM, Stephen Kelly wrote:
That is, parameters to install(TARGETS) are evaluated at export time, and
otherwise the contents of the property are reproduced verbatim.
Yes, I think this makes sense. The install rules run as part of
the current project's
Brad King wrote:
I've pushed a INCLUDES-DESTINATION-partial-eval topic to my clone with
some ideas for it. Please let me know what you think.
Are you proposing this for inclusion in 2.8.12?
Yes.
IMO it can wait along with the rest.
As INCLUDES DESTINATION is already in master, that would
Brad King wrote:
The bug report is about adding genex support to those destinations.
Yes, it's also the one that started this thread. Do we agree that
full generate-time evaluation is appropriate for these? If so then
the implementation will require BUILD_TYPE conditional blocks in
Brad King wrote:
What about the tll() version?
target_link_libraries(foo PRIVATE )
seems to not be an error with master already.
Changing that behavior is something I'd recommend deferring to after
2.8.12 if you want to change it. I don't feel extremely strongly about
keeping it strict.
Brad King wrote:
So, I think for the case of INCLUDES DESTINATION, we can either decide
and fix it now, or revert the change adding it for 2.8.12.
Let's try to decide now and revert as a last resort.
So the only reason we need partial evaluation is to leave
configuration-dependent
Brad King wrote:
On 07/31/2013 11:05 AM, Stephen Kelly wrote:
Config sensitive dirs are likely more common for libraries
than includes, so actually I think it would be fine to make that an error
and always do full evaluation.
To clarify, the no-config rule is for INCLUDES DESTINATION only
Hi there,
it would be useful for KDE Frameworks to have ALIAS targets in CMake 2.8.12.
http://thread.gmane.org/gmane.comp.kde.devel.core/80233/focus=80247
I finished the topic and pushed it to next in case it can go into that
release.
I won't be available most of today to change it if
Brad King wrote:
The topic looks like a great start. I won't promise to take it
for 2.8.12 yet but let's proceed with review.
- The documentation in add_library and add_executable lists a bunch
of things one can't do but not an example of what one can do.
I think this documentation
Brad King wrote:
On 08/02/2013 08:00 AM, Brad King wrote:
No, I think just a prose list of example uses e.g. linking into other
targets.
Thanks for the other fixes.
FYI, I added this to your topic:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9a0a1945
to fix the AliasTarget
Alexander Neundorf wrote:
On Monday 29 July 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
So it can be used in tll() calls to link against the library (package).
What makes it differ from Foo_LIBRARIES, is that CMake checks that each
of the items listed in this variable
Rolf Eike Beer wrote:
Am Sonntag, 28. April 2013, 13:57:26 schrieb Rolf Eike Beer:
One question I see increasingly often is how do I test for C++11
support or for specific parts of that. For 2.8.12 I plan to include the
check module I wrote for that a while back, and that I have reworked in
is that it would check for stuff on any compiler I throw
on it, so it would just report correct results for this that haven't been
tested before (PGI? MipsPro? gcc 2?).
...
Stephen Kelly wrote:
I suggest you use CMAKE_CXX_COMPILER_ID and CMAKE_CXX_COMPILER_VERSION to
hardcode the features. You could
Rolf Eike Beer wrote:
Stephen Kelly wrote:
Rolf Eike Beer wrote:
Given that you're gathering the versions of each feature availability
anyway, and given that boost.config and qcompilerdetection.h have the
same information, there is no need for all users of the module to run
all
Hi there,
I can use a trivial toolchain file to compile for QNX with qcc:
SET(CMAKE_SYSTEM_NAME QNX)
SET(arch gcc_ntoarmv7le)
SET(CMAKE_C_COMPILER qcc -V${arch})
SET(CMAKE_CXX_COMPILER QCC -V${arch})
SET(CMAKE_FIND_ROOT_PATH $ENV{QNX_TARGET}/armle-v7 $ENV{QNX_TARGET})
Brad King wrote:
On 08/06/2013 05:39 AM, Daniele E. Domenichelli wrote:
I added a commit introducing a couple of unit tests that should run only
if GTK and/or GTKMM are available on the system.
Thanks. Steve, please take a quick look at this topic to
review how the imported targets are
Daniele E. Domenichelli wrote:
Hello Stephen,
Thanks for the review
On 09/08/13 10:50, Stephen Kelly wrote:
* What is GTK2_GDKCONFIG_INCLUDE_DIR compared to GTK2_GDK_INCLUDE_DIR?
Can you conditionally append GTK2_GDKCONFIG_INCLUDE_DIR if it is not
STREQUAL GTK2_GDK_INCLUDE_DIR?
GTK2
Rolf Eike Beer wrote:
5)
This is not nice API:
#if defined (CXXFEATURES_NULLPTR_FOUND)
void *nix = nullptr;
#else /* CXXFEATURES_NULLPTR_FOUND */
void *nix = 0;
#endif /* CXXFEATURES_NULLPTR_FOUND */
Much better would be:
void *nix = CXXFEATURES_NULLPTR;
where -DCXXFEATURES_NULLPTR=0 or
Stephen Kelly wrote:
I still think you should revisit my review mail on point 2 too.
Something that becomes possible when thinking about the above and target
properties is interface requirements.
If my library uses 'final' unguarded by macros in my headers, then I want to
communicate through
Daniele E. Domenichelli wrote:
On 12/08/13 15:36, Stephen Kelly wrote:
The difference is that if GTK2_USE_IMPORTED_TARGETS the
GTK_${_var}_LIBRARY will link the target (and it's dependencies)
otherwise it will link only the library (without dependencies) using the
DEBUG or RELEASE version
Hi,
I pushed a branch updating the version number of new policies and a version
number generated in export files a few months ago. I just left it as a
reminder to bump merge the bumps at RC time. The branch was deleted soon
after though.
Is the release branch going to get a similar change
Brad King wrote:
I added a commit to update the versions:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07c16eec
I'll have to re-create the release branch tomorrow after this
is tested.
You missed the version in
Source/cmExportInstallFileGenerator.cxx
See commit 574fec97fd011
Brad King wrote:
On 08/14/2013 10:59 AM, Stephen Kelly wrote:
Brad King wrote:
I added a commit to update the versions:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07c16eec
I'll have to re-create the release branch tomorrow after this
is tested.
You missed the version
Brad King wrote:
On 08/14/2013 11:00 AM, Brad King wrote:
On 08/14/2013 10:59 AM, Stephen Kelly wrote:
Brad King wrote:
I added a commit to update the versions:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=07c16eec
I'll have to re-create the release branch tomorrow after
Stephen Kelly wrote:
Stephen Kelly wrote:
I still think you should revisit my review mail on point 2 too.
Something that becomes possible when thinking about the above and target
properties is interface requirements.
I've implemented a prototype which has better API than your module
Robert Maynard wrote:
Some of the notable changes in this release are:
Some other things that I think are release-notes-worthy:
- New PUBLIC PRIVATE and INTERFACE options for target_link_libraries
- New ALIAS targets feature
- Automatically process Headers directory of Frameworks on Apple as
Alexander Neundorf wrote:
I don't see any particular reason to get it into 2.8.12. From the KDE
perspective, I think it would be more useful to get a CMake version with
ALIAS targets
I still don't know what for.
Can it do anything I can't do by simply setting a variable to the aliased
Brad King wrote:
On 08/22/2013 04:39 PM, Alexander Neundorf wrote:
Beside that, I played around with it a bit.
If 2.8.12 is required, it errors out, as documented.
If I use 2.8.12 and require 2.8.11:
[snip]
So this seems to behave differently than in 2.8.11 even if 2.8.11 is
required
Brad King wrote:
On 08/15/2013 08:37 AM, Stephen Kelly wrote:
target_compiler_feature(target PUBLIC|PRIVATE
REQUIRED feature1 [feature2 ...])
target_compiler_feature(target PUBLIC|PRIVATE
OPTIONAL feature DEFINE define_name)
Doesn't this require the language (CXX) to be specified
Brad King wrote:
On 08/27/2013 05:56 PM, Stephen Kelly wrote:
and the expected results and will be useful for you to
write a more complete solution.
I'm sure Eike can do it too. Or at least get started with encoding the
detection results into platform files and refactoring the detection
Hi there,
There are a few concepts in CMake whose documentation is dotted around
various places, but without a single location to learn about the concept
itself, how it should be used, and what needs to be kept in mind when using
it.
A new documentation section for concepts could be
Hi there,
I've rebased and pushed the INTERFACE_LIBRARY-target-type branch to my clone
again.
I'd like to get this one in to the next release soon after it opens for
features, but there are still a few things to discuss about how it should
work.
Relevant previous threads:
Alexander Neundorf wrote:
The consensus was that it's a good idea, but it needs better linking
within the documentation:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5924
Too bad about the bikeshedding.
The point is not about de-duplication (though that can also be
Stephen Kelly wrote:
Hi there,
I've rebased and pushed the INTERFACE_LIBRARY-target-type branch to my
clone again.
See also proof of concept here:
https://github.com/purpleKarrot/BoostCMake/pull/1
which is the ongoing work to use CMake for boost using ALIAS targets,
INTERFACE
Brad King wrote:
Yes, versioning is a good idea to think about.
write_compiler_detection_header(
FILE ${CMAKE_CURRENT_BINARY_DIR}/grantlee_compiler_detection.h
PREFIX Grantlee_
VERSION 3
)
This could help somewhat because we could change what is produced
by a newer version while still
Stephen Kelly steveire@... writes:
Matthew Woehlke wrote:
Perhaps that is a misreading on my part, but I was getting the
impression this change would make it so that imported targets can only
ever be SYSTEM.
I didn't really make that clear as the discussion developed, but yes, I
think
Brad King wrote:
On 08/29/2013 11:14 AM, Stephen Kelly wrote:
Another option would be not to have the VERSION in the signature, but
always use CMAKE_MINIMUM_VERSION_REQUIRED to determine what to generate.
The content generated depends only on the features of the cmake binary
being run, so
Brad King wrote:
On 08/30/2013 08:02 AM, Stephen Kelly wrote:
It turns out that in order to do this, the compiler features would
have to be listed independently of Modules/Compiler/${ID}.cmake.
Otherwise I wouldn't be able to check the MSVC features while using GNU.
Maybe they should
Brad King wrote:
BTW, I think a better name may be language features rather than
compiler features because we are declaring features of language
versions and variants, not of the compilers.
I don't agree with that. We are enumerating/introspecting the features of
the compiler. The fact
Hi there,
On the QtCreator list recently there was a discussion about installing
projects which use cmake to device targets:
http://thread.gmane.org/gmane.comp.lib.qt.creator/8995
The want to transfer files without invoking make install. I think the only
reason for that is because it could
Daniele E. Domenichelli wrote:
Hello Stephen,
Sorry for the delay, but I was on holiday...
On 14/08/13 15:07, Stephen Kelly wrote:
Daniele E. Domenichelli wrote:
I did a few more tests, and it looks like that, at least on my system
and on windows, FREETYPE_LIBRARIES are not required
Brad King wrote:
3) I have left a TODO note in cmLocalGenerator.cxx about the return value
from GetRealDependency.
Callers of GetRealDependency are looking for a file-level dependency.
Targets like OBJECT_LIBRARY and INTERFACE_LIBRARY have no real file
on which to depend. The
Brad King wrote:
On 08/30/2013 06:49 AM, Stephen Kelly wrote:
I've pushed the IMPORTED-target-SYSTEM-includes topic to my clone for
review.
It introduces a policy-controlled default handling of
INTERFACE_INCLUDE_DIRECTORIES from IMPORTED targets as SYSTEM. It also
introduces a default
Stephen Kelly wrote:
7) I've only implemented the support for this target type in the
Makefile generator so far. I can also do the Ninja one after all of the
details about how it works are sorted out.
Can someone else implement the VS and Xcode support? I'm too unfamiliar
with those
Brad King wrote:
Can you please teach it to print out the value of each of the two
properties so we have some hint about what is different?
I pushed print-CMP0022-content-conflict and merged it to next.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source
Hi there,
http://open.cdash.org/viewTest.php?onlyfailedbuildid=3027577
shows some failures which I can't reproduce as I don't have VS6. Can you
help finding/fixing the problem?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
Brad King wrote:
On 09/13/2013 07:21 AM, Stephen Kelly wrote:
http://open.cdash.org/viewTest.php?onlyfailedbuildid=3027577
shows some failures which I can't reproduce as I don't have VS6. Can you
help finding/fixing the problem?
Not enough of the VS generators is turned off
Brad King wrote:
On 08/28/2013 03:28 PM, Stephen Kelly wrote:
We should add these concept sections to the docs and we can add 'See the
documentation of the generator_expression concept' where it makes sense.
We should not change or extend the markup or make adding these concept
sections
Alexander Neundorf wrote:
On Saturday 14 September 2013, Stephen Kelly wrote:
Brad King wrote:
On 08/28/2013 03:28 PM, Stephen Kelly wrote:
We should add these concept sections to the docs and we can add 'See
the documentation of the generator_expression concept' where it makes
sense
Hi there,
I've pushed the Qt-auto-generators topic to my clone.
https://gitorious.org/cmake/steveires-cmake/commits/Qt-auto-generators
It is a proof of concept for features similar to AUTOMOC, but for invoking
the uic and rcc tools shipped with Qt. I'd like to generalize the AUTOMOC
Hello,
In CMake, the MODULE_LIBRARY type is quite like a shared library which is
not linked to. In Qt, there is a concept of a static plugin. This is
essentially just a static library, but there is buildsystem awareness of the
difference.
When building a static library using Qt, the
Brad King wrote:
On 09/20/2013 08:14 AM, Stephen Kelly wrote:
Any comments on adding a new STATIC_MODULE type to CMake?
Other than the TYPE being a different name, how would CMake
treat this target type differently?
In the case of Qt, I don't see much else relevantly different between
Brad King wrote:
So the answer is, 'probably nothing'.
In that case I do not think we can justify a special CMake
target type for it. All the special cases for STATIC_LIBRARY
targets will have to be updated to also account for the new
type with no difference in logic.
Another alternative
Brad King wrote:
On 09/20/2013 01:40 PM, Stephen Kelly wrote:
macro(qt_add_plugin name type)
if (${type} STREQUAL STATIC OR ${type} STREQUAL MODULE)
set(_type ${type})
set(args ${ARGN})
else()
set(_type MODULE)
set(args ${type} ${ARGN})
endif()
add_library(${name
Hello,
Consider this:
add_library(foo SHARED ...)
add_library(bar SHARED ...)
target_link_libraries(foo LINK_PRIVATE bar)
install(TARGETS foo EXPORT FooTargets ...)
install(TARGETS bar EXPORT BarTargets ...)
install(EXPORT FooTargets ...)
install(EXPORT BarTargets ...)
This is very
Brad King wrote:
Steve, please explain your proposal in more detail. How does the list of
requested features get mapped to the proper -std=cxx11 or equivalent flag?
In my branch that is determined by which list the feature appears in. Eg,
from GNU-CXX.cmake:
if(NOT
Brad King wrote:
Steve, Eike,
Now that 2.8.12 is tagged I'd like to revive the work to support
C++11 features.
I met Eike in person today at Qt DevDays and talked about this topic a bit.
The way forward is for me to get the infrastructure in place by cleaning up
my branch. I'll aim for
Hello,
I pushed a export-at-generate-time topic to my clone. It changes the
behavior of export() to be executed at generate-time by default, unless the
result is include()d (policy CMP0024).
This is needed to be able to have multiple dependent export sets in the
build directory. I make use
Brad King wrote:
On 10/10/2013 12:57 PM, Brad King wrote:
On 10/10/2013 12:09 PM, Stephen Kelly wrote:
For example:
http://open.cdash.org/viewBuildError.php?buildid=3055146
It seems that machine is not processing the $TARGET_FILE genex. Any
idea why?
That requires CMake = 2.8.4
Brad King wrote:
On 10/10/2013 11:10 AM, Stephen Kelly wrote:
I pushed a export-at-generate-time topic to my clone. It changes the
behavior of export() to be executed at generate-time by default, unless
the result is include()d (policy CMP0024).
This is needed to be able to have multiple
Brad King wrote:
On 10/09/2013 10:44 AM, Stephen Kelly wrote:
if(NOT needs17 EQUAL -1)
set(standard 17)
elseif(NOT needs14 EQUAL -1)
set(standard 14)
elseif(NOT needs11 EQUAL -1)
set(standard 11)
endif()
# ...
set_property(TARGET ${TARGET_NAME} PROPERTY CXX_STANDARD
Brad King wrote:
On 10/09/2013 12:21 PM, Rolf Eike Beer wrote:
One thing that is currently unclear if the simulated compiler id stuff
from Brad solves the problem of the Clang plugin running with gcc where
one would get the gcc version as compiler version but the features are
actually
Brad King wrote:
On 10/10/2013 08:55 PM, Stephen Kelly wrote:
Brad King brad.king@... writes:
I just checked the VS 6, 9 and 11 IDEs and it is possible to mark
a source file as excluded from certain configurations. Those versions
represent all the VS generators.
If listing all sources
Brad King wrote:
On 10/10/2013 08:07 PM, Stephen Kelly wrote:
So, I think this is a two dimensional calculation. There is a standard
axis and a extension axis for the compiler flag, for GCC and clang at
least.
Yes.
if (NOT CMAKE_CXX_COMPILER_VERSION VERSION_LESS 4.7)
set
Brad King wrote:
Steve,
Please extend the CMP0026 message to suggest file(GENERATE)
as a way of putting the target location in a generated file.
Some projects not supporting multi-config generators may
use LOCATION with configure_file.
Done.
Can the policy NEW behavior instead be to
Stephen Kelly wrote:
I'll try to get a reviewable and first-feature-complete infrastructure
branch together soon.
I've pushed a first iteration of the target_compiler_features branch to my
clone.
For the language specification, I added a prefix to each feature. This
matches the feature
Brad King wrote:
On 10/16/2013 02:40 PM, James Bigler wrote:
The documentation for target_link_libraries has this description:
target_link_libraries(target
LINK_PRIVATE|LINK_PUBLIC
[[debug|optimized|general] lib] ...
Brad King wrote:
Optional features with defines are not yet implemented. I was considering
renaming target_compiler_features to target_required_features
I think target_compiler_features is a clearer name even if it only
supports required features. Please leave room in the signature for
Brad King wrote:
On 10/17/2013 04:58 PM, Alexander Neundorf wrote:
Yes, that was the idea, but I can't rely anymore on a Foo_LIBRARIES
variable (or a slight variation) being set after a successful
find_package(Foo):
http://lists.kde.org/?l=kde-core-develm=138198795723680w=2 I.e. in the
Brad King wrote:
On 10/21/2013 04:05 PM, Stephen Kelly wrote:
I'm still not sure that generating a header specific to the compiler (ID
and version) is a good idea.
[snip]
So, I think maybe it would make sense to list features separately, and if
someone does this:
I thought we had reached
To: Stephen Kelly steve...@gmail.com
Hi Stephen,
It has between pointed out to me on IRC that CMake automatically adds
the install prefix path (CMAKE_INSTALL_PREFIX)
to CMAKE_SYSTEM_PREFIX_PATH - which is included in the paths searched.
This is rather unfortunate as it interferes in our CI system - we
Alexander Neundorf wrote:
Is the only solution to this as Ben describes with
passing NO_CMAKE_SYSTEM_PATH to CMake?
Is everything installed into its own separate directory, or everything
into one common install directory ?
Everything is installed to a separate directory, and each one is
Brad King wrote:
CMAKE_CXX_COMPILER is always set to the proper full path these days,
even in the IDE generators, so I wonder if we could actually run it
against the header file to detect the features available for the
current compiler instead of hard-coding a table in the platform
Brad King wrote:
On 10/23/2013 05:59 PM, Stephen Kelly wrote:
CMAKE_CXX_COMPILER is always set to the proper full path these days,
even in the IDE generators, so I wonder if we could actually run it
against the header file to detect the features available for the
current compiler instead
Hello,
My install prefix currently looks something like this:
l -1 /home/stephen/dev/prefix/qtbase/kde/doc/
cmake-2.8/
cmake-2.8.12.20131023-g07324-dirty/
cmake-2.8.12.20131023-g10e02-dirty/
cmake-2.8.12.20131023-g1bfc2/
cmake-2.8.12.20131023-g3dec3/
cmake-2.8.12.20131023-g5a601/
Alexander Neundorf wrote:
On Thursday 24 October 2013, Stephen Kelly wrote:
Hi,
I've pushed the Qt-auto-generators topic to stage. This topic was
discussed here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7936
I have tested it with ports of KDE Frameworks
701 - 800 of 1193 matches
Mail list logo
