On 10/9/2011 11:35 AM, Alexander Neundorf wrote:
But doesn't this still have the same problem ?
I mean, if "LINK_PUBLIC" is at the end of a ${FOO_LIBS} variable, everything
put after it will be PUBLIC:
target_link_libraries(Foo LINK_PRIVATE lib1 lib2 ${FOO_LIBS} lib3)
with FOO_LIBS being e.g. "
On Thursday 06 October 2011, Brad King wrote:
> On 10/5/2011 9:47 AM, Stephen Kelly wrote:
> > Thanks for all of your explanations. It seems that introducing a way to
> > do this with one command has some support.
> >
> > So if SOME_FEATURE is true,
> >
> > target_link_libraries(foo bar SOME_KEYW
Bill Hoffman wrote:
> On 10/7/2011 11:30 AM, Brad King wrote:
>> On 10/7/2011 11:23 AM, Stephen Kelly wrote:
>>> Brad King wrote:
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
in a consistent stat
Stephen Kelly wrote:
> Stephen Kelly wrote:
>
>> Stephen Kelly wrote:
>>
such that kwtyle is run as a pre-commit hook.
>>>
>>> The instructions don't seem to work:
>>>
>>
>> Oops, they do work. I had missed the part about creating a new repo in my
>> hooks dir.
>
> :/
>
> Not
2011/10/7 Stephen Kelly :
> Stephen Kelly wrote:
>
>> Stephen Kelly wrote:
>>
such that kwtyle is run as a pre-commit hook.
>>>
>>> The instructions don't seem to work:
>>>
>>
>> Oops, they do work. I had missed the part about creating a new repo in my
>> hooks dir.
>
> :/
>
> Not fi
Stephen Kelly wrote:
> Stephen Kelly wrote:
>
>>>
>>> such that kwtyle is run as a pre-commit hook.
>>>
>>
>> The instructions don't seem to work:
>>
>
> Oops, they do work. I had missed the part about creating a new repo in my
> hooks dir.
:/
Not finding some conf file:
stephen@hal:~/dev/
Stephen Kelly wrote:
>>
>> such that kwtyle is run as a pre-commit hook.
>>
>
> The instructions don't seem to work:
>
Oops, they do work. I had missed the part about creating a new repo in my
hooks dir.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.k
Eric Noulard wrote:
> 2011/10/7 Stephen Kelly
> :
>> Bill Hoffman wrote:
>
>>> Please keep working on fixing the dashboard, there are a few style
>>> errors here:
>>> http://www.cdash.org/CDash/viewBuildError.php?buildid=1601031
>>>
>>> -Bill
>>>
>>
>> Hmm, hadn't noticed those.
>>
>> The li
2011/10/7 Stephen Kelly :
> Bill Hoffman wrote:
>>>
>> Please keep working on fixing the dashboard, there are a few style
>> errors here:
>> http://www.cdash.org/CDash/viewBuildError.php?buildid=1601031
>>
>> -Bill
>>
>
> Hmm, hadn't noticed those.
>
> The link doesn't show useful information. How
Bill Hoffman wrote:
> On 10/7/2011 11:30 AM, Brad King wrote:
>> On 10/7/2011 11:23 AM, Stephen Kelly wrote:
>>> Brad King wrote:
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
in a consistent stat
On 10/7/2011 11:30 AM, Brad King wrote:
On 10/7/2011 11:23 AM, Stephen Kelly wrote:
Brad King wrote:
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
in a consistent state.
Done.
Also, I think the documentat
On 10/7/2011 11:23 AM, Stephen Kelly wrote:
Brad King wrote:
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
in a consistent state.
Done.
Also, I think the documentation can be simplified for that signature
Brad King wrote:
> On 10/6/2011 8:54 PM, Stephen Kelly wrote:
>> Well that didn't take long. I pushed a target-link-libraries-interfaces
>> branch to stage.
>
> Good start. Please change the three Doing*Interface modes into an
> enumeration so we don't have to worry about keeping three booleans
On 10/6/2011 8:54 PM, Stephen Kelly wrote:
Well that didn't take long. I pushed a target-link-libraries-interfaces
branch to stage.
Good start. Please change the three Doing*Interface modes into an
enumeration so we don't have to worry about keeping three booleans
in a consistent state. Also,
On 10/6/2011 8:01 PM, Stephen Kelly wrote:
Do you mean a library or target called LINK_INTERFACE_DEPENDENCIES? Or do
you mean like this:
target_link_libraries(somelib ${ARGS_FROM_SOMEWHERE_ELSE})
where the variable could be a list containing the term
LINK_INTERFACE_DEPENDENCIES?
The latter
Stephen Kelly wrote:
> target_link_libraries(foo
> LINK_PUBLIC
> qtcore
> qtnetwork
> )
>
> is equivalent to
>
> target_link_libraries(foo
> qtcore
> qtnetwork
> )
>
> * foo will link against qtcore and qtnetwork
I should have also noted that both qtcore and qtnetwork will also be in the
LINK
Stephen Kelly wrote:
>> Other possible names? Perhaps LINK_PUBLIC and LINK_PRIVATE?
>> Perhaps LINK AND LINK_ONLY?
>
> I'll implement it as you suggest with LINK_PUBLIC and LINK_PRIVATE, which
> are most clear to me. We can change it once we have an implementation to
> talk about.
Well that did
Brad King wrote:
> On 10/5/2011 9:47 AM, Stephen Kelly wrote:
>> Thanks for all of your explanations. It seems that introducing a way to
>> do this with one command has some support.
>>
>> So if SOME_FEATURE is true,
>>
>> target_link_libraries(foo bar SOME_KEYWORD baz)
>> if (SOME_FEATURE)
>>
On 10/5/2011 9:47 AM, Stephen Kelly wrote:
Thanks for all of your explanations. It seems that introducing a way to do
this with one command has some support.
So if SOME_FEATURE is true,
target_link_libraries(foo bar SOME_KEYWORD baz)
if (SOME_FEATURE)
target_link_libraries(foo mar SOME_KEYWO
Brad King wrote:
> On 10/4/2011 10:22 PM, Stephen Kelly wrote:
>> 1) Change the meaning of LINK_INTERFACE_LIBRARIES in
>>
>> set_target_properties(foo LINK_INTERFACE_LIBRARIES bar)
>
> Do you mean target_link_libraries, rather than set_target_properties?
> The latter is a very general command and
On 10/4/2011 10:22 PM, Stephen Kelly wrote:
1) Change the meaning of LINK_INTERFACE_LIBRARIES in
set_target_properties(foo LINK_INTERFACE_LIBRARIES bar)
Do you mean target_link_libraries, rather than set_target_properties?
The latter is a very general command and will not be taught special
beh
Stephen Kelly wrote:
>
> Hi David,
>
> This is related to my patch to set the link_interface_libraries to empty
> and to:
>
> http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030
>
> Quoting:
>
>> Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
>> By
On Monday, October 03, 2011 08:50:23 am Rolf Eike Beer wrote:
> Am Montag, 3. Oktober 2011, 07:59:45 schrieb Clinton Stimpson:
> > On Oct 3, 2011, at 3:25 AM, Rolf Eike Beer wrote:
> > > Am Samstag, 1. Oktober 2011, 22:51:55 schrieb Clinton Stimpson:
> > >> On Oct 1, 2011, at 4:48 PM, Rolf Eike Bee
Am Montag, 3. Oktober 2011, 07:59:45 schrieb Clinton Stimpson:
> On Oct 3, 2011, at 3:25 AM, Rolf Eike Beer wrote:
> > Am Samstag, 1. Oktober 2011, 22:51:55 schrieb Clinton Stimpson:
> >> On Oct 1, 2011, at 4:48 PM, Rolf Eike Beer wrote:
> >>> On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundor
Am Montag, 3. Oktober 2011, 10:50:25 schrieb Alexander Neundorf:
> On Sunday 02 October 2011, Rolf Eike Beer wrote:
> > On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf
> >
>
> wrote:
> > > If library bar internally uses symbols from foo,
> > > it needs to link against foo.
> >
> > Corre
Am Samstag, 1. Oktober 2011, 22:51:55 schrieb Clinton Stimpson:
> On Oct 1, 2011, at 4:48 PM, Rolf Eike Beer wrote:
> > On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf
wrote:
> >> If library bar internally uses symbols from foo,
> >> it needs to link against foo.
> >
> > Correct.
> >
>
On Sunday 02 October 2011, Rolf Eike Beer wrote:
> On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf
wrote:
> > If library bar internally uses symbols from foo,
> > it needs to link against foo.
>
> Correct.
>
> > But if bar doesn't expose symbols from foo in its
> > interface, and my ex
On Oct 1, 2011, at 10:51 PM, Clinton Stimpson wrote:
>
> On Oct 1, 2011, at 4:48 PM, Rolf Eike Beer wrote:
>
>> On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf
>> wrote:
>>
>>> If library bar internally uses symbols from foo,
>>> it needs to link against foo.
>>
>> Correct.
>>
>>>
On Oct 1, 2011, at 4:48 PM, Rolf Eike Beer wrote:
> On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf
> wrote:
>
>> If library bar internally uses symbols from foo,
>> it needs to link against foo.
>
> Correct.
>
>> But if bar doesn't expose symbols from foo in its
>> interface, and m
On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf
wrote:
> If library bar internally uses symbols from foo,
> it needs to link against foo.
Correct.
> But if bar doesn't expose symbols from foo in its
> interface, and my executable hello links against bar, it doesn't also
> have to be
On Saturday 01 October 2011, Stephen Kelly wrote:
> Hi David,
>
> This is related to my patch to set the link_interface_libraries to empty
> and to:
>
> http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030
>
> Quoting:
> > Setting LINK_INTERFACE_LIBRARIES to empty is still n
Hi David,
This is related to my patch to set the link_interface_libraries to empty and
to:
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030
Quoting:
> Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
> By default, all libraries a target is linked
On Sat, Oct 1, 2011 at 6:37 AM, Stephen Kelly wrote:
>
> Hi,
>
> Currently setting the link dependencies and the link interface involves a
> lot of repetition. It is necessary to call target_link_libraries twice:
>
> target_link_libraries(radiobuttonmodel
> ${QT_QTCORE_LIBRARIES}
> ${QT_QTGUI_LI
Hi,
Currently setting the link dependencies and the link interface involves a
lot of repetition. It is necessary to call target_link_libraries twice:
target_link_libraries(radiobuttonmodel
${QT_QTCORE_LIBRARIES}
${QT_QTGUI_LIBRARIES}
${QT_QTNETWORK_LIBRARIES}
)
target_link_libraries(radi
34 matches
Mail list logo
