On Tue, Jun 4, 2013 at 3:38 PM, Brad King brad.k...@kitware.com wrote:
On 06/03/2013 03:38 PM, Nicolas Tessore wrote:
As far as I can see, there is just one possible issue with this.
Say there is libfoo.a in two locations, ie. /usr/lib and
/usr/local/lib. If /usr/lib comes first in
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.
This failed on one of
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
On 06/05/2013 10:06 AM, Stephen Kelly wrote:
The reason is that fix-genex-HEAD-target is not yet merged to master. Sorry,
I should have been clear about the dependency between those branches.
It is now, after I squashed in this fix:
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3a7898ab
On 06/05/2013 10:02 AM, Stephen Kelly wrote:
I think a clean break is a better idea.
Then why not have a new command for linking? Your proposal makes
*all* the old and new tll() signatures completely separate and not
usable on a single target. It is essentially a new command with
the same
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?
There will be some
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
On 06/05/2013 10:48 AM, Stephen Kelly wrote:
Brad King wrote:
Can you present an argument for why it is not a good idea?
As far as I remember, I couldn't find a way to implement it completely.
Unfortunately I don't remember the details and I don't seem to have my
experiments in a branch.
On Wed, Jun 5, 2013 at 7:45 AM, Stephen Kelly steve...@gmail.com wrote:
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
On Jun 04, 2013, at 04:17 PM, Brad King brad.k...@kitware.com wrote:The discussion that led to that change was here: http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2523/focus=2530The predicating problem is curious. If a pthreads library was no longer being detected, that would
Christopher Sean Morrison wrote:
On Jun 04, 2013, at 04:17 PM, Brad King brad.k...@kitware.com wrote:
The discussion that led to that change was here:
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/2523/focu
s=2530
The predicating problem is curious. If a pthreads
On Jun 05, 2013, at 02:57 PM, Rolf Eike Beer e...@sf-mail.de wrote: It possible to quell that conversion warning. Perhaps something like this: ((char *)(long)SYMBOL)[argc] + 1 This will cause errors on those platforms where long and void* are not the same size, i.e. Windows64.Yes, uintptr_t
On 06/05/2013 01:43 PM, Christopher Sean Morrison wrote:
p.s. CHECK_PROTOTYPE_EXISTS is practically useless as written. I'd submit
a patch to fix it, but the fix would look nearly identical to what
CHECK_SYMBOL_EXISTS used to test.
Perhaps that is the path forward for your need.
Before
My build_projects CMake project now contains ExternalProject_Add
build configurations for 5 different software projects which build
cleanly on Linux using the default Unix Makefiles generator on
that platform and which build cleanly on the MinGW/MSYS/Wine
platform using the MSYS Makefiles
On Jun 05, 2013, at 04:10 PM, Brad King brad.k...@kitware.com wrote:On 06/05/2013 03:16 PM, Christopher Sean Morrison wrote: getting past GCC's pedantic point about direct type conversion. If the user tests with -Werror that warning could be a problem, so that flag is worth stripping if
On Jun 05, 2013, at 04:14 PM, Brad King brad.k...@kitware.com wrote:Before working on a patch, can you explain why the current check is "practically useless"?I actually don't see the function in the current tree. Maybe someone else already realized how bad it was.. ;)Looks like it was maybe
19 matches
Mail list logo
