Moving this to the developer list where I meant it to be, rather than on
the cmake users list. Sorry for anyone who gets it twice.
I am looking for a way to set global flags for the librarian when creating
static libraries, similar to CMAKE_SHARED_LINKER_FLAGS
or CMAKE_EXE_LINKER_FLAGS. This wo
David Cole wrote:
> On Thu, Dec 6, 2012 at 3:37 PM, Stephen Kelly
> wrote:
>
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/3615/focus=5111
>>
>> I'm not sure what has changed since then.
>>
> What's changed since then is that we've seen how much change is needed for
> the fea
Alexander Neundorf wrote:
> On Thursday 06 December 2012, Stephen Kelly wrote:
> ...
>> I don't fully follow (too much 'the example' etc :)), but I guess it's
>> not too important. I think the two cases we're talking about are clear
>>
>> * Installing to a location where one or more locations bel
Brad King wrote:
> I'm picturing this as just a simple reStructuredText document in a branch
> of your repo. If anyone (like Alex) wants to join the discussion there
> will be one place to look for the current status.
I don't like the idea of using a branch in a repo. It would require checking
Brad King wrote:
> On 12/06/2012 03:53 PM, Stephen Kelly wrote:
>> Brad King wrote:
>>> How can we ever stop exporting the old interface when it comes from the
>>> link implementation?
>>
>> The approach I was thinking was to deal with it the same way we deal with
>> LINK_PUBLIC and LINK_PRIVATE
On Thu, Dec 6, 2012 at 3:37 PM, Stephen Kelly wrote:
> Alexander Neundorf wrote:
>
> > Hi,
> >
> > I haven't followed the long thread between Brad and Stephen about
> > importing and exporting targets closely...
> >
> > So, if I understand correctly, in the future the following cmake code
> >
> >
On Thursday 06 December 2012, Stephen Kelly wrote:
...
> I don't fully follow (too much 'the example' etc :)), but I guess it's not
> too important. I think the two cases we're talking about are clear
>
> * Installing to a location where one or more locations below
> ${CMAKE_INSTALL_PREFIX} are sy
Alexander Neundorf wrote:
>> I also think it's a very bad idea to install into a prefix where one of
>> the directories below it is a symlink to somewhere else. I think that
>> also deserves a warning.
>
> See below, you can get the same problem if you install into a prefix where
> there is no sy
On 12/06/2012 03:53 PM, Stephen Kelly wrote:
> Brad King wrote:
>> How can we ever stop exporting the old interface when it comes from the
>> link implementation?
>
> The approach I was thinking was to deal with it the same way we deal with
> LINK_PUBLIC and LINK_PRIVATE - Make it depend on the p
On 12/06/2012 03:55 PM, Stephen Kelly wrote:
> Brad King wrote:
>> Let's keep the proposed changes in your Gitorious clone at
>>
>> https://gitorious.org/~steveire/cmake/steveires-cmake
>>
>> for now. If I need to push commits I'll publish them somewhere similar.
>
> So what are the next steps?
On Thursday 06 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Thursday 06 December 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > On Thursday 06 December 2012, Stephen Kelly wrote:
> >> >> Alexander Neundorf wrote:
> >> >> > Let's assume /opt/foo/lib/ is a
Alexander Neundorf wrote:
> On Thursday 06 December 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > On Thursday 06 December 2012, Stephen Kelly wrote:
>> >> Alexander Neundorf wrote:
>> >> > Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
>> >> > The package has been insta
Brad King wrote:
> On 12/06/2012 08:08 AM, Stephen Kelly wrote:
>> There is another twist in the tail here. The existing topic on next is
>> not taking account of the case where the link implementation is the link
>> interface when exporting.
>
> After considering this issue and the concerns Alex
Brad King wrote:
> On 12/06/2012 08:08 AM, Stephen Kelly wrote:
>> There is another twist in the tail here. The existing topic on next is
>> not taking account of the case where the link implementation is the link
>> interface when exporting.
>
> Yes, of course :(
>
> How can we ever stop export
On Thursday 06 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > On Thursday 06 December 2012, Stephen Kelly wrote:
> >> Alexander Neundorf wrote:
> >> > Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
> >> > The package has been installed to /opt/foo/ and is found via
Alexander Neundorf wrote:
> On Thursday 06 December 2012, Stephen Kelly wrote:
>> Alexander Neundorf wrote:
>> > Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
>> > The package has been installed to /opt/foo/ and is found via
>> > CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.
Alexander Neundorf wrote:
> Hi,
>
> I haven't followed the long thread between Brad and Stephen about
> importing and exporting targets closely...
>
> So, if I understand correctly, in the future the following cmake code
>
> find_package(Foo)
>
> add_executable(hello main.cpp)
>
> target_link
On Thursday 06 December 2012, Alexander Neundorf wrote:
...
> I'd much prefer the following:
>
> find_package(Foo NO_MODULE)
>
> add_executable(hello main.cpp)
>
> target_use_targets(hello Foo::FooLibrary)
which could even warn if a used library doesn't have include directory
properties set, e
On Thursday 06 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
> > The package has been installed to /opt/foo/ and is found via
> > CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.cmake.
> > Now when going up to t
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
> There is another twist in the tail here. The existing topic on next is not
> taking account of the case where the link implementation is the link
> interface when exporting.
After considering this issue and the concerns Alex raised in the new
"Setti
Alexander Neundorf wrote:
> Let's assume /opt/foo/lib/ is a symlink to /usr/local/lib/.
> The package has been installed to /opt/foo/ and is found via
> CMAKE_PREFIX_PATH in /opt/foo/lib/cmake/Foo/FooConfig.cmake.
> Now when going up to the prefix, we will come across /opt/foo/lib/, which
> is a sy
On Tuesday 04 December 2012, Stephen Kelly wrote:
> Alexander Neundorf wrote:
> > All install variables which are at cmake time somewhere below
> > CMAKE_INSTALL_PREFIX are treated as relative to CMAKE_INSTALL_PREFIX.
> > This is what the @PAKCAGE_INIT@ macro together with the @PACKAGE_FOO_DIR@
> >
Hi,
I haven't followed the long thread between Brad and Stephen about importing
and exporting targets closely...
So, if I understand correctly, in the future the following cmake code
find_package(Foo)
add_executable(hello main.cpp)
target_link_libraries(hello ${Foo_LIBRARIES})
may also set
On 12/06/2012 08:08 AM, Stephen Kelly wrote:
> There is another twist in the tail here. The existing topic on next is not
> taking account of the case where the link implementation is the link
> interface when exporting.
Yes, of course :(
How can we ever stop exporting the old interface when it
Brad King wrote:
> On 11/29/2012 02:48 PM, Stephen Kelly wrote:
>> So maybe I should only do the expansion if containsVariable is true?
>>
>>
+//
>> +static bool containsVariable(const std::string &lib)
>> +{
>> + const
On 11/29/2012 02:48 PM, Stephen Kelly wrote:
> So maybe I should only do the expansion if containsVariable is true?
>
> +//
> +static bool containsVariable(const std::string &lib)
> +{
> + const std::string::size_type ope
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13778
==
Reported By:David Imhoff
Assigned To:
Sorry please forget this message.
On Thu, Dec 6, 2012 at 7:10 AM, Amit Kulkarni wrote:
> Brad,
>
> Is it possible for you to accept this chunk from
> http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/devel/cmake/patches/patch-Modules_Platform_OpenBSD_cmake
>
> $OpenBSD: patch-Modules_Platfor
Brad,
Is it possible for you to accept this chunk from
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/devel/cmake/patches/patch-Modules_Platform_OpenBSD_cmake
$OpenBSD: patch-Modules_Platform_OpenBSD_cmake,v 1.9 2012/12/05
11:32:04 dcoppa Exp $
--- Modules/Platform/OpenBSD.cmake.orig Tue
Brad King wrote:
> Anyway, I think once the LINK_PUBLIC part of the policy is worked
> out then I'll perform one final review pass through the topic.
> I'd also like to have the CMP0019 test added to it covering the
> current form of the policy (since it's changed since you wrote the
> test before
On 12/06/2012 07:48 AM, Amit Kulkarni wrote:
> Ok. Attached is the modified set of patches for OpenBSD qt3/qt4 handling.
>
> Commit message: Handle OpenBSD specific paths in Qt3/Qt4, allowing concurrent
> building and installation. Some common programs to both qt3/qt4 are renamed
> with suffixes
> > Similarly find_program already looks in /usr/local/bin.
> >
> > I suspect the patch without the above hunks is sufficient. Can anyone
> > on OpenBSD verify this please?
>
> Confirmed. "/usr/local" hunks are not needed.
>
> Thanks,
> David
Ok. Attached is the modified set of patches for Ope
32 matches
Mail list logo
