Stephen Kelly wrote:
> Yes, apart from tll-new-signatures, I'd like to try to get the
> export-policy and target-LOCATION-policy topics from my clone into 2.8.12.
Actually, the export-policy branch deprecates the ability to write code like
export(TARGETS foo FILE fooTargets.cmak
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 we should set the priority on the former for 2.8.12
> since it is the culmination of your work fo
Brad King wrote:
> Both roles are already widely used. There is user code that:
>
> * Sets CMAKE_INSTALL_PREFIX to change the install dest (role 1).
> * Uses CMAKE_INSTALL_PREFIX as the target install dest (role 2).
>
> Moving one role into a separate variable will require user code for
> at lea
Brad King wrote:
>>> If that problem manifests in practice we can add a special hook to
>>> enable the workaround.
>>
>> If I understand you, this doesn't sound like an attractive solution to
>> me.
>
> If we go with CMAKE_TARGET_INSTALL_PREFIX as I describe above
> then we can simply use that to
Brad King wrote:
>>> Any project-specific place that needs to know the on-target path
>>> can use a project-specific variable.
>>
>> Yes, I suppose. What I was suggesting was to standardise that.
>
> Okay, but I'd rather keep CMAKE_INSTALL_PREFIX to mean where on the
> host it will be installed
Stephen Kelly wrote:
> Nope, this is really not about that.
I mean 'not really', but it's also part of the story.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep mes
Brad King wrote:
> On 07/10/2013 11:17 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>
>>> On 7/4/2013 4:29 AM, Stephen Kelly wrote:
>>>> I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH
>>>> which can't be done with
Brad King wrote:
> IIUC currently real library paths like foo.framework/foo have no
> special handling right now. They are (correctly) not split and
> there is no include directory added for them.
Correct.
> So, the question is: do we want to add *new* special handling for
> library paths insid
Brad King wrote:
> On 7/4/2013 4:29 AM, Stephen Kelly wrote:
>> I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH
>> which can't be done with CMAKE_PREFIX_PATH (with a bit more repetition on
>> the command line, I think). Should we enum
Brad King wrote:
> IIRC we have the same problem with inter-target dependencies and
> we solved it by taking the union of dependencies from all configs.
> Is that right?
Yes, I think that's right.
> I don't think that solution can work for source files.
> Perhaps for Xcode we can generate wrappe
Stephen Kelly writes:
> We could also probably add a runtime warning if enabled. You need to enable
> deprecation warnings with your compiler, so it would make sense to have to
> enable them with a cmake script too. CMAKE_ENABLE_DEPRECATION_WARNINGS
> could be used to determin
Hi,
I've been looking into a patch to add an include directory automatically
when a framework is used. For example:
target_link_libraries(sometarget LINK_PRIVATE ${FOO})
if ${FOO}/.. is a framework path, then add ${FOO}/.. to the
INCLUDE_DIRECTORIES of sometarget (at generate time).
This me
Hi there,
Yesterday I merged (and then reverted) the compile-defs-debugging branch
into next. It was failing with the VS generators.
Today I added a hack to handle semicolons specially. It's not a very good or
exact solution, but it seems to make the Preprocessor test pass again.
The problem
Brad King writes:
>
> On 06/07/2013 09:13 AM, Stephen Kelly wrote:
> >SOURCES $<$:other.cpp>
>
> That has been requested as a feature occasionally. I'm not sure
> it is possible to implement on all the generators though.
>
I looked into this a bit an
Brad King wrote:
> On 7/8/2013 3:58 PM, Stephen Kelly wrote:
>> Yesterday I made a commit to set CMAKE_LEGACY_CYGWIN_WIN32 as suggested,
>> but it did not silence the warning. I don't know where the warning comes
>> from.
>
> The first project() call is
One of the dashboards is failing currently on this branch:
http://open.cdash.org/testDetails.php?test=197185916&build=2959788
The problem is that the test expects an empty stderr because the policy
warning is expected not to be issued.
However, another warning is issued:
actual-err> CMake
Brad King wrote:
> On 7/8/2013 11:22 AM, Stephen Kelly wrote:
>> Brad King wrote:
>>> or do you mean that CMAKE_HOST_INSTALL_PREFIX, if defined at all,
>>> completely replaces CMAKE_INSTALL_PREFIX for all install rules?
>>
>> Yes for install rules, but wi
Brad King wrote:
> On 7/8/2013 9:31 AM, Brad King wrote:
>> Yes, but how does install() know that "foo" is for the host
>> or the target?
>
> or do you mean that CMAKE_HOST_INSTALL_PREFIX, if defined at all,
> completely replaces CMAKE_INSTALL_PREFIX for all install rules?
Yes for install rules,
Brad King wrote:
> On 7/8/2013 9:06 AM, Stephen Kelly wrote:
>> I was thinking of cases where the install DESTINATION is relative:
>>
>> install(TARGETS foo ... DESTINATION lib)
>>
>> If CMAKE_HOST_INSTALL_PREFIX is defined, foo is installed to
>>
Brad King wrote:
> On 07/04/2013 04:29 AM, Stephen Kelly wrote:
>>> How do install() invocations distinguish which prefix to use?
>>
>> I think install invokations use CMAKE_HOST_INSTALL_PREFIX for everything
>> if present, and CMAKE_INSTALL_PREFIX otherwise.
>
Stephen Kelly wrote:
>
> Hi there,
>
> I've written a greasmonkey script to reorder the results on
>
> http://open.cdash.org/queryTests.php?project=CMake&date=&limit=200
Or rather,
http://open.cdash.org/queryTests.php?project=CMake&date=&limit=20
Brad King wrote:
> On 7/1/2013 1:26 PM, Stephen Kelly wrote:
>> I've pushed a proof-of-concept multiple-toolchains branch to my clone
>> which enables the use of multiple toolchains with cmake.
>
> Wow, that is a mind-blowing branch ;)
That's a good reacti
Brad King wrote:
> Oops, I should have noticed that while reviewing the CMAKE_SYSROOT topic.
> This will need to be a per-language flag. Please replace that with
> something like
>
> CMAKE__COMPILE_OPTIONS_SYSROOT
>
Done.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware o
Alexander Neundorf wrote:
>> For the Qt configure, the answer is the latter, and I think it makes
>> sense. As CMAKE_SYSROOT is new, we can still change the behavior to that.
>> I tend to think we should.
>
> Not quite sure.
> I tend to agree.
>
> Different question: is CMAKE_FIND_ROOT_PATH actu
Hi there,
I've collected the following links:
http://developer.apple.com/library/mac/#DOCUMENTATION/DeveloperTools/Conceptual/cross_development/Configuring/configuring.html#//apple_ref/doc/uid/1163i-CH1-SW2
To choose an SDK, you use the -isysroot option with the compiler and the -
syslibr
Hi there,
Given a generic toolchain file like this:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_C_COMPILER "arm-linux-gnueabihf-gcc")
set(CMAKE_CXX_COMPILER "arm-linux-gnueabihf-g++")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROO
Clinton Stimpson wrote:
>> As a feature, would it make sense to make that unnecessary in a future
>> CMake version?
>>
>
> How would you make it unecessary?
> Would you change CMake so the include directory would automatically be
> included for frameworks specified in target_link_libraries()? T
Clinton Stimpson wrote:
> Yeah, I understand that is the issue.
> I don't quite get what is new for Qt 5.1. I thought Qt 4.x only installed
> Qt headers inside the framework too. Perhaps its new from 5.0 to 5.1?
Yes.
>
> On a Mac with a prebuilt Qt 4.7
> qmake -query QT_INSTALL_HEADERS => /us
Brad King wrote:
> AddInterfaceDepends gets the dependencies from the immediate link
> interface but not the whole link interface transitive closure.
Thanks for investigating. Should be fixed now.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http
Brad King wrote:
> A few other tests have had the same problem.
I think I've fixed them all now.
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
Brad King wrote:
> On 06/27/2013 06:42 PM, Stephen Kelly wrote:
>> Brad King wrote:
>>>
>>> The current topic looks pretty good and I will perform more
>>> testing soon.
>>
>> Sounds good! I'll test it more too.
>
> The
Clinton Stimpson wrote:
>
> This change hasn't been released yet and will go into CMake 2.8.12.
Ah, I see. I was mis-reading my gitk.
> If Qt were to put multiple versions of libraries into one framework, then
> I think the IMPORTED_LOCATION should be more specific.
The issue is more about
Hi there,
I've pushed a proof-of-concept multiple-toolchains branch to my clone which
enables the use of multiple toolchains with cmake.
The idea is to use a separate cache and set of definition overrides for each
toolchain. The current proof-of-concept implementation is very simple and
makef
Clinton Stimpson wrote:
>
> With the refactor IMPORTED_LOCATION in generated export files went from
> /path/to/foo.framework/foo
> to
> /path/to/foo.framework/Version/A/foo
> That change naturally came out of the refactor.
>
> Since for non-frameworks, the property is the location of the actual
Stephen Kelly wrote:
> He said it was interesting that full paths to the dynamic libs are used
> instead of -F and --frameworks entries. That probably relates to how the
> IMPORTED_LOCATION of the target is populated.
I asked him to hack the macro calls to
_populate_Core_target_p
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 line
Hi there,
For the new Qt release candidate, include files which used to be installed
are no longer installed:
https://bugreports.qt-project.org/browse/QTBUG-32134
http://download.qt-project.org/development_releases/qt/5.1/5.1.0-rc2/
The header files are no longer installed to $PREFIX/includ
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
Matthew Woehlke wrote:
> 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 a
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
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?
Yes, that is the approach I took before, which is still available as
5343c596db797f063300226069f219668d70a399 (Process the export() comm
Brad King wrote:
> Steve,
>
> Please take a look at this failure:
>
> http://open.cdash.org/testDetails.php?test=196577461&build=2949683
> expanded command line '...' too long
>
> I think the GeneratorExpression test needs to be split into
> even more parts.
>
Yep, that was expected eventua
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:
target_li
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:
> 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):
>
> target_li
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 conditio
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
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
http://www.
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)
Brad King wrote:
> The build of the project itself will not change, and even
> external consumers will behave the same if they are built
> with the same version of CMake.
It's confusing to me that so much of what you wrote is stuff I'm obviously
already familiar with, having implemented a few pol
Brad King wrote:
> On 6/26/2013 12:24 PM, Stephen Kelly wrote:
>> EXPORT_LINK_INTERFACE_LIBRARIES option
>
> I think the generated targets file will need to bump its
> minimum required version of CMake if the policy is NEW
> and the compatibility export option is not used.
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
Brad King wrote:
> On 06/26/2013 11:16 AM, Stephen Kelly wrote:
>> http://open.cdash.org/testDetails.php?test=196514636&build=2948288
>>
>> The unit test seems to be exposing a bug in the Xcode generator or in the
>> handling of the COMPILE_OPTIONS target p
Brad King wrote:
> On 06/07/2013 09:36 AM, Brad King wrote:
>> Great. One more part to think about is how the warning can work
>> for the interface policy.
> * OLD behavior uses the old properties for everything
> (tll sets them, cmTarget reads them)
> * NEW behavior uses the new property for
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, whi
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=1&name=ExportImport&date=2013-06-25
> http://open.cdash.org/testDetails.
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 f
Hi there,
The ExportImport test is failing with two Xcode dashboards (but not the
other xcode dashboards)
http://open.cdash.org/testSummary.php?project=1&name=ExportImport&date=2013-06-25
http://open.cdash.org/testDetails.php?test=196266835&build=2946532
clang: error: no such file or direc
Robert Maynard wrote:
> @@ -666,7 +666,7 @@ public:
> */
> const std::vector& 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,
S
Brad King wrote:
> On 06/11/2013 07:35 AM, Stephen Kelly wrote:
>> # CMake workarounds
>> set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_TOOLCHAIN_LINK_FLAGS} CACHE INTERNAL
>> "exe link flags") set(CMAKE_MODULE_LINKER_FLAGS
>> ${CMAKE_TOOLCHAIN_LINK_FLAGS} CACHE
Stephen Kelly wrote:
> # CMake workarounds
> set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_TOOLCHAIN_LINK_FLAGS} CACHE INTERNAL
> "exe link flags")
Even with this hack, it doesn't work until I hack
CMakeDetermineCompilerABI.cmake too to overwrite, not append
Hi there,
Here is a toolchain file that I can use (after a few pending merges to
CMake) to cross compile things for the RaspberryPi with clang:
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSROOT "/home/stephen/rpi/rasp-pi-rootfs/")
set(triple arm-linux-gnueabihf)
set(CMAKE_LIBRARY_ARCHITECTUR
Brad King wrote:
> On 06/07/2013 09:13 AM, Stephen Kelly wrote:
>>SOURCES $<$: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
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:
> 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
> dashb
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 &
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 go
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
Brad King wrote:
> On 06/06/2013 11:15 AM, Stephen Kelly wrote:
>>> Also it may be tricky due to the way $ is
>>> currently handled up front.
>>
>> You mean TARGET_OBJECTS? It seems to only populate a ObjectLibraries
>> container which is later onl
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
dis
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.
>>
Brad King wrote:
> On 06/06/2013 01:33 PM, Stephen Kelly wrote:
>> 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 c
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 pr
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 languag
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 ac
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 t
Hi,
I've been working on a patch to make it easier to use CMake with a
statically built Qt 5:
https://codereview.qt-project.org/#change,56215
A complexity arises in that all Qt 5 applications must load a platform
plugin. If Qt is built statically, the platform plugin must be loaded by
using
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
htt
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 argume
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 p
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 ar
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
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 f
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 requireme
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 tar
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
>
&
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 etc
Clinton Stimpson wrote:
> On Monday, June 03, 2013 10:09:41 AM Stephen Kelly wrote:
>> 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 so
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
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 Source
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
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
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 gen
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
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 ca
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 t
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-
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 cha
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
> i
Brad King wrote:
>> http://open.cdash.org/testDetails.php?test=157289612&build=2905507
>
> 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 joi
601 - 700 of 1446 matches
Mail list logo
