On 09/28/2012 04:56 PM, Brad King wrote:
> On 09/28/2012 04:21 PM, Alexander Neundorf wrote:
>> There is an updated version now on stage.
>>
>> The behaviour of cmExportBuildFileGenerator now basically is the same as it
>> was before.
>> The collected target exports are not considered at all anymo
On 09/28/2012 04:21 PM, Alexander Neundorf wrote:
> There is an updated version now on stage.
>
> The behaviour of cmExportBuildFileGenerator now basically is the same as it
> was before.
> The collected target exports are not considered at all anymore, error
> handling
> and APPEND mode should
On Friday 28 September 2012, Alexander Neundorf wrote:
> On Friday 28 September 2012, Brad King wrote:
> > On 09/28/2012 01:21 PM, Alexander Neundorf wrote:
> > > The imported target bld_testExe2lib in ExportBuildTree.cmake links
> > > against the imported target exp_testExe2libImp created in exp.c
On Friday 28 September 2012, Brad King wrote:
> On 09/28/2012 01:21 PM, Alexander Neundorf wrote:
> > The imported target bld_testExe2lib in ExportBuildTree.cmake links
> > against the imported target exp_testExe2libImp created in exp.cmake.
> >
> > So if exp.cmake is included after ExportBuildTre
On 09/28/2012 01:21 PM, Alexander Neundorf wrote:
> The imported target bld_testExe2lib in ExportBuildTree.cmake links against
> the
> imported target exp_testExe2libImp created in exp.cmake.
>
> So if exp.cmake is included after ExportBuildTree.cmake this imported library
> does not exist yet.
On Friday 28 September 2012, Brad King wrote:
> On 09/24/2012 08:19 AM, Brad King wrote:
> > On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
> >> This is now in the export-sets-2 branch on stage, including a basic
> >> test.
> >>
> >> Comments ? Ok to merge into next ?
> >
> > Yes, thanks.
>
>
On 09/24/2012 08:19 AM, Brad King wrote:
> On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
>> This is now in the export-sets-2 branch on stage, including a basic test.
>>
>> Comments ? Ok to merge into next ?
>
> Yes, thanks.
This commit is a problem:
http://cmake.org/gitweb?p=cmake.git;a=comm
On 09/23/2012 01:22 PM, Alexander Neundorf wrote:
> This is now in the export-sets-2 branch on stage, including a basic test.
>
> Comments ? Ok to merge into next ?
Yes, thanks.
-Brad
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/o
On Friday 21 September 2012, Alexander Neundorf wrote:
> On Thursday 20 September 2012, Brad King wrote:
> > On 09/20/2012 12:20 PM, Alexander Neundorf wrote:
> > > if(NOT TARGET Foo)
> > >
> > >if(CMAKE_FIND_PACKAGE_NAME)
> > >
> > > set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
> >
On Thursday 20 September 2012, Brad King wrote:
> On 09/20/2012 12:20 PM, Alexander Neundorf wrote:
> > if(NOT TARGET Foo)
> >
> >if(CMAKE_FIND_PACKAGE_NAME)
> >
> > set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
>
> What happens if other imported targets have already been defined?
> T
On 09/20/2012 12:20 PM, Alexander Neundorf wrote:
> if(NOT TARGET Foo)
>if(CMAKE_FIND_PACKAGE_NAME)
> set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
What happens if other imported targets have already been defined?
Then the targets file will have been partially loaded.
> set(${CMAKE_
On Thursday 20 September 2012, Brad King wrote:
> On 09/19/2012 04:14 PM, Alexander Neundorf wrote:
> > On Wednesday 19 September 2012, Alexander Neundorf wrote:
> >> Hmm, I was almost done implementing it...
> >> when creating the export file, we do not know how the Config file will
> >> be named,
On 09/19/2012 04:14 PM, Alexander Neundorf wrote:
> On Wednesday 19 September 2012, Alexander Neundorf wrote:
>> Hmm, I was almost done implementing it...
>> when creating the export file, we do not know how the Config file will be
>> named, i.e. we do not know the name of the package, so we cannot
On Wednesday 19 September 2012, Alexander Neundorf wrote:
> On Tuesday 18 September 2012, Brad King wrote:
> > On 09/18/2012 04:12 PM, Alexander Neundorf wrote:
> > > How about defining a variable which can be set by Config-files which
> > > holds an error message for the case that the Config-file
On Tuesday 18 September 2012, Brad King wrote:
> On 09/18/2012 04:12 PM, Alexander Neundorf wrote:
> > How about defining a variable which can be set by Config-files which
> > holds an error message for the case that the Config-file has set
> > _FOUND to FALSE ?
> > Like e.g. _FIND_FAILURE_MESSAGE
On 09/18/2012 04:12 PM, Alexander Neundorf wrote:
> How about defining a variable which can be set by Config-files which holds an
> error message for the case that the Config-file has set _FOUND to
> FALSE
> ?
> Like e.g. _FIND_FAILURE_MESSAGE ?
> This could then be printed by cmFindPackage and/
On Monday 17 September 2012, Alexander Neundorf wrote:
> On Monday 17 September 2012, Alexander Neundorf wrote:
> > On Monday 17 September 2012, Brad King wrote:
> > > On 09/15/2012 04:45 PM, Alexander Neundorf wrote:
> > > > There is now a branch export-sets-2 on cmake stage.
> > > > It cherry-pic
On Monday 17 September 2012, Alexander Neundorf wrote:
> On Monday 17 September 2012, Brad King wrote:
> > On 09/15/2012 04:45 PM, Alexander Neundorf wrote:
> > > There is now a branch export-sets-2 on cmake stage.
> > > It cherry-picks a lot of the patches from
> > > http://gitorious.org/~urkud1/c
On Mon, Sep 17, 2012 at 4:35 PM, Alexander Neundorf wrote:
> How should the APPEND mode of EXPORT() be handled ?
> Could you please have a look at
> cmExportFileGenerator::SetImportLinkProperty(..)
> whether this looks ok ?
The APPEND mode used to mean the project is on its own to handle
dependen
On Monday 17 September 2012, Brad King wrote:
> On 09/15/2012 04:45 PM, Alexander Neundorf wrote:
> > There is now a branch export-sets-2 on cmake stage.
> > It cherry-picks a lot of the patches from
> > http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set,
> > mostly those from May,
On Monday 17 September 2012, Brad King wrote:
> On 09/17/2012 03:52 PM, Alexander Neundorf wrote:
> > On Monday 17 September 2012, Brad King wrote:
> >> What would you do instead of aborting? Silently pretend the package
> >> Bar was not found at the current Bar_DIR and move on with the search?
>
On 09/17/2012 03:52 PM, Alexander Neundorf wrote:
> On Monday 17 September 2012, Brad King wrote:
>> What would you do instead of aborting? Silently pretend the package
>> Bar was not found at the current Bar_DIR and move on with the search?
>> That would require the sandboxing I previously elabor
On Monday 17 September 2012, Brad King wrote:
> On 09/17/2012 03:35 PM, Alexander Neundorf wrote:
> > Let's say FooTargets.cmake provides the target foo.
> >
> > BarTargets.cmake provides the target bar, and requires FooTargets.cmake.
> >
> > Now if the user installed the bar-devel package, but n
On 09/17/2012 03:35 PM, Alexander Neundorf wrote:
> Let's say FooTargets.cmake provides the target foo.
>
> BarTargets.cmake provides the target bar, and requires FooTargets.cmake.
>
> Now if the user installed the bar-devel package, but not the foo-devel
> package, the target foo will not be av
On Monday 17 September 2012, Brad King wrote:
> On 09/17/2012 03:14 PM, Alexander Neundorf wrote:
> > On Monday 17 September 2012, Brad King wrote:
> >>> I guess I have to handle the error case better than simply erroring
> >>> out.
> >>
> >> Not IMO. Remember my message here:
> > I think this is
On 09/17/2012 03:14 PM, Alexander Neundorf wrote:
> On Monday 17 September 2012, Brad King wrote:
>>> I guess I have to handle the error case better than simply erroring out.
>>
>> Not IMO. Remember my message here:
>
> I think this is different.
> Here, in this case, it may fail because the requ
On Monday 17 September 2012, Brad King wrote:
> On 09/15/2012 04:45 PM, Alexander Neundorf wrote:
> > There is now a branch export-sets-2 on cmake stage.
> > It cherry-picks a lot of the patches from
> > http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set,
> > mostly those from May,
2012/9/16 Alexander Neundorf :
> On Tuesday 11 September 2012, Brad King wrote:
>> On 09/11/2012 04:08 PM, Yury G. Kudryashov wrote:
>> > 2012/9/11 Alexander Neundorf :
>> >> Hi Yury,
>> >>
>> >> will you be able to work on this for the 2.8.10 release ?
>> >
>> > What are the deadlines?
>>
>> Featu
2012/9/17 Brad King :
> On 09/15/2012 04:45 PM, Alexander Neundorf wrote:
> Also, one of Yury's commit messages says:
>
> TODO: remove another clear() because it doesn't delete TargetExports.
>
> What is that about?
clear() on a vector of TargetExport* does not call delete on each element.
BTW, d
On 09/15/2012 04:45 PM, Alexander Neundorf wrote:
> There is now a branch export-sets-2 on cmake stage.
> It cherry-picks a lot of the patches from
> http://gitorious.org/~urkud1/cmake/urkud-cmake/commits/w/export-set, mostly
> those from May, and then proceeds a bit differently.
>
> In the end,
On Tuesday 11 September 2012, Brad King wrote:
> On 09/11/2012 04:08 PM, Yury G. Kudryashov wrote:
> > 2012/9/11 Alexander Neundorf :
> >> Hi Yury,
> >>
> >> will you be able to work on this for the 2.8.10 release ?
> >
> > What are the deadlines?
>
> Features not finished by the end of Septembe
On 09/11/2012 04:08 PM, Yury G. Kudryashov wrote:
> 2012/9/11 Alexander Neundorf :
>> Hi Yury,
>>
>> will you be able to work on this for the 2.8.10 release ?
> What are the deadlines?
Features not finished by the end of September may not be included.
-Brad
--
Powered by www.kitware.com
Visit o
2012/9/11 Alexander Neundorf :
> Hi Yury,
>
> will you be able to work on this for the 2.8.10 release ?
What are the deadlines?
--
Yours Yury,
mailto: urkud.ur...@gmail.com
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.htm
Hi Yury,
On Thursday 23 August 2012, Yury G. Kudryashov wrote:
> Hi!
>
> 2012/8/23 Daniel Pfeifer :
> > 2012/8/22 Yury G. Kudryashov :
> >>> Any "latest install" strategy is bound to generate subtle problems.
> >>>
> >>> Dependencies among export sets should be explicit:
> >>> install(EXPORT M
On 08/23/2012 04:20 AM, Yury G. Kudryashov wrote:
> Hi!
> 2012/8/23 Daniel Pfeifer :
>> 2012/8/22 Yury G. Kudryashov :
Any "latest install" strategy is bound to generate subtle problems.
Dependencies among export sets should be explicit:
install(EXPORT MyExport DEPENDS YourExp
Hi!
2012/8/23 Daniel Pfeifer :
> 2012/8/22 Yury G. Kudryashov :
>>> Any "latest install" strategy is bound to generate subtle problems.
>>> Dependencies among export sets should be explicit:
>>>
>>> install(EXPORT MyExport DEPENDS YourExport)
>> How should I choose between different
>> install(EX
2012/8/22 Yury G. Kudryashov :
> 2012/8/23 Brad King :
>> On 08/22/2012 04:57 PM, Yury G. Kudryashov wrote:
>>> I'm going to push the current state of my work to
>>> git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git w/export-set
>>> in a few minutes.
>>
>> Thanks for working on this!
>>
>>
2012/8/23 Brad King :
> On 08/22/2012 04:57 PM, Yury G. Kudryashov wrote:
>> I'm going to push the current state of my work to
>> git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git w/export-set
>> in a few minutes.
>
> Thanks for working on this!
>
>> It should work, though I haven't tested
On 08/22/2012 04:57 PM, Yury G. Kudryashov wrote:
> I'm going to push the current state of my work to
> git pull git://gitorious.org/~urkud1/cmake/urkud-cmake.git w/export-set
> in a few minutes.
Thanks for working on this!
> It should work, though I haven't tested it yet. The idea is simple:
> e
Hi,
2012/8/23 Alexander Neundorf :
> Hi,
>
> If I would do this, I would get the error for the BarExport export set, that
> it does not contain target foo, which it depends on.
>
> We'd like to make this work, since we need this in KDE.
>
> How can this be done ?
Sorry for the very long silence. I
On 08/22/2012 04:15 PM, Alexander Neundorf wrote:
> add_library(foo SHARED foo.c)
>
> install(TARGETS foo EXPORT FooExport DESTINATION lib )
> install(TARGETS foo EXPORT FooExportX DESTINATION libx )
>
> install(EXPORT FooExport DESTINATION lib/foo )
> install(EXPORT FooExport NAMESPACE "Foo::"
Hi,
currently, when exporting library targets, it is required that all in-project
libraries which the exported libraries depend on, are also exported in the
same export set.
I.e. the following currently does not work:
add_library(foo SHARED foo.c)
install
42 matches
Mail list logo
