Brad King wrote:
> On 09/20/2013 12:03 PM, Stephen Kelly wrote:
>> if (my_lib_type STREQUAL SHARED)
>>add_library(some_plugin MODULE main.cpp)
>> else()
>>add_library(some_plugin STATIC
>> SOURCES main.cpp
>> PROPERTIES
>>
Eric Noulard wrote:
> 2013/9/20 Stephen Kelly
> :
>> Stephen Kelly writes:
>>> https://gitorious.org/~steveire/cmake/steveires-cmake
>>>
>>> It is the start of a CPack generator for BlackBerry BAR packages,
>>> required for deployment to tho
Brad King wrote:
> IMO that's too special-purpose. However, since it is so common to
> add a library and then set properties on it, perhaps there should be
> a syntax in add_library and add_executable to inline property settings.
>
> For example, we could add a keyword signature to declare SOURCE
Stephen Kelly writes:
> 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 feedback
Stephen Kelly wrote:
> Any comments?
>
Clinton, Brad, Alex, any comments on this?
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:
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 alter
Brad King wrote:
> On 09/20/2013 08:54 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> Other than the TYPE being a different name, how would CMake
>>> treat this target type differently?
>>
>> So the answer is, 'probably nothing'.
>
> In
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 el
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 QT_STATI
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
feature
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 documentatio
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 mark
Brad King wrote:
> On 09/13/2013 07:21 AM, Stephen Kelly wrote:
>> http://open.cdash.org/viewTest.php?onlyfailed&buildid=3027577
>>
>> shows some failures which I can't reproduce as I don't have VS6. Can you
>> help finding/fixing the problem?
>
>
Hi there,
http://open.cdash.org/viewTest.php?onlyfailed&buildid=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
http://www.kitware.co
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 proj
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 impl
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 ta
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 OBJ
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
>>&
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 b
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 fa
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 us
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 f
Stephen Kelly 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 d
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 w
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 AL
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 s
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:
http://thread.gm
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 introduce
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
Brad King wrote:
> On 08/15/2013 08:37 AM, Stephen Kelly wrote:
>> target_compiler_feature(
>>REQUIRED [ ...])
>> target_compiler_feature(
>>OPTIONAL DEFINE )
>
> Doesn't this require the language (CXX) to be specified somewhere?
> Perhaps
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
>>
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 alias
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
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 bett
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=07c16e
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 relea
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 574fec9
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 fo
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 d
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
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;
>>
>> w
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_D
Brad King wrote:
> Steve,
>
> Have you tested this feature extensively?
I've built some hello world size projects and I've built gammaray with qcc
with a toolchain file defining it.
> Does it follow through try_compile checks and such?
If the CMAKE__COMPILER_TARGET are set in the toolchain
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
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})
set(CMAKE_FIND_ROOT
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, t
at you're talking about, but I am certain you're mistaken in
a simple interpretation of what you wrote.
> The idea I
> have about CMake 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
&g
Brad King wrote:
> On 08/05/2013 02:08 AM, Rolf Eike Beer wrote:
>> s...@rogue-research.com wrote:
>>> very confusingly, Apple uses their own version numbering scheme. So
>>> that's "Apple clang 4.0". It comes with whatever version of Xcode that
>>> machine's running (4.4 I think?).
>>
>> any v
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 rewor
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
>> >
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 th
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 documentati
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 neede
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-
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:
> 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 s
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:
>> 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
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
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/29/2013 06:57 PM, Stephen Kelly wrote:
>> Yes, $ 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
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
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 i
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 $ genex
> would be useful in this case.
Yes, $ should work
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
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 thin
Nicolas Desprès wrote:
> On Mon, Jul 29, 2013 at 12:57 PM, Stephen Kelly
> 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
>&g
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.
>
Brad King wrote:
> Please add an error condition when INCLUDES DESTINATION is used
> without EXPORT and a test case to cover it.
I added that, but I think it would be better to remove the error case.
In KDE we have a INSTALL_TARGETS_DEFAULT_ARGS variable, used like this:
install(TARGETS klib1
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 open-s
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 signa
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#
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 wit
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 does exactly that.
>
>
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?
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
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 a
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 target
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 feedba
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 t
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 blo
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.
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.
>
D
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 stage/framework-inter
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 framework-in
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
Stephen Kelly wrote:
> Brad King wrote:
>
>> Steve,
>>
>> Our discussions recently have been divided between two general
>> areas of enhancement:
>>
>> * Usage requirements and interface libraries
>> * Cross-compiling
>>
>> I think
Brad King wrote:
> Steve,
>
>
> I merged this topic, consisting of commits a18e9586..d7dd0108,
> to master this morning. However, when I use the VS generators
> on Windows CMake now crashes because something clobbers the
> cmMakefile::SourceGroups member. This didn't crash when the
> topic was
Brad King wrote:
> On 7/15/2013 11:25 AM, Stephen Kelly wrote:
>> The solution I think is to add the specified include directories to the
>> cmTargetExport instance which gets created when using the EXPORT, and to
>> append the directories only when generating.
>
>
Brad King wrote:
> Steve,
>
> From the documentation of the feature:
>
> + "The INCLUDES DESTINATION specifies a list of directories which
> will "
> + "be added to the INTERFACE_INCLUDE_DIRECTORIES of the
> when "
> + "exported by install(EXPORT). If a relative path is specifie
Brad King wrote:
> On 07/04/2013 04:29 AM, Stephen Kelly wrote:
>> Goals:
>> * Install to /opt/kf5 on the target
>> * Install to $HOME/dev/kf5 on the host
>
> Steve, why do we need to have the host location not end in the
> target's install prefix?
For me, i
Nicolas Desprès wrote:
>> Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can
>> send you a gzipped of my callgrind data off-list if you want (it
>> weights 534K).
>>
> If we had a map associating each input to output, we could maybe have
> better performance. WDYT?
Perhaps. I
Nicolas Desprès wrote:
>>> > I have pushed my work so far on my github clone of CMake.
>>> > https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
>>>
Thanks. The bottleneck seems to be in
cmTargetTraceDependencies::FollowName
as it follows each entry in the LARGE_LIST for each of
Stephen Kelly wrote:
>
> This result is surprising:
>
>
http://open.cdash.org/testSummary.php?project=1&name=RunCMake.ObsoleteQtMacros&date=2013-07-12
>
> There is a QT4_WORKS test in Tests/CMakeLists.txt. Is that hiding this
> issue in other Qt4 based unit
Nicolas Desprès wrote:
> I have pushed my work so far on my github clone of CMake.
> https://github.com/nicolasdespres/CMake/tree/topic/large-deps-perf
Something must have gone wrong with the push :)
stephen@hal:~/dev/src/cmake{master}$ git show origin/master | grep commit
commit b9412889e9c502
This result is surprising:
http://open.cdash.org/testSummary.php?project=1&name=RunCMake.ObsoleteQtMacros&date=2013-07-12
There is a QT4_WORKS test in Tests/CMakeLists.txt. Is that hiding this issue
in other Qt4 based unit tests? Rather than hiding the issue, and idea what's
going on?
Than
Alexander Neundorf wrote:
> Hi,
>
> I was surprised today, something worked which I expected to fail:
>
Can you say which version of cmake this did fail with?
Note that it is more likely to *compile* since 2.8.11 because includes and
defines are part of the target interface, but linking shoul
clin...@elemtech.com wrote:
> What is the motivation for deprecating these?
> Can we just let them fade away on their own as the world moves from Qt4 to
> Qt5?
This is entirely orthogonal to Qt 5.
qt4_use_modules is new, but provides no benefit over tll(). We shouldn't
encourage adoption of it
Brad King wrote:
> On 07/11/2013 11:08 AM, Brad King wrote:
>> Can anyone else think of complications?
>
> Side note: If we cannot resolve this soon we should revert
> CMAKE_SYSROOT before 2.8.12 to leave room for the two to
> be combined later.
I've reverted it now. I've also removed the replac
501 - 600 of 1446 matches
Mail list logo
