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.
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 state.
Done.
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.
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
in a
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
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
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 state.
Done.
Eric Noulard wrote:
2011/10/7 Stephen Kelly
steve...@gmail.com:
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
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
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:
2011/10/7 Stephen Kelly steve...@gmail.com:
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
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 finding some conf file:
I might
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)
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 didn't
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
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
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 default, all
On Sunday 02 October 2011, Rolf Eike Beer wrote:
On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf neund...@kde.org
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
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 Neundorf
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 Beer wrote:
On Sat, Oct 1, 2011 at 6:37 AM, Stephen Kelly steve...@gmail.com 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}
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 Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf neund...@kde.org
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
On Oct 1, 2011, at 4:48 PM, Rolf Eike Beer wrote:
On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf neund...@kde.org
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,
24 matches
Mail list logo
