Re: packaging Calligra: common dependencies?

2016-12-27 Thread René J . V . Bertin
On Tuesday December 27 2016 16:39:27 Friedrich W. H. Kossebau wrote:

> Currently the Calligra buildsystem expects the shared libs being part of the 
> sources that are build, not being imported from the outside. There is no 
> support for that.
> 
> So pruning is what you will need to do currently.

That also means that you'll end up with lots of conflicting (= already 
installed) items if you build, say, Words and Sheets separately?

The problem is that there's a *lot* to prune, and it becomes increasingly 
tricky to do this correctly when you start adding packages.

R.


Re: packaging Calligra: common dependencies?

2016-12-27 Thread Friedrich W. H. Kossebau
Am Sonntag, 25. Dezember 2016, 12:06:42 CET schrieb René J.V. Bertin:
> Hi,
> 
> Sorry in advance if I could have scraped this information from the build
> instructions:
> 
> I'm starting to look at creating MacPorts ports for Calligra (starting with
> Karbon). I see that it's possible to build and package a set of Calligra
> libraries and components shared among all or a major subset of components.
> That's great because with the MacPorts approach the build and packaging
> steps are linked, meaning it's not possible to build everything once and
> then generate packages for individual components.

Currently the Calligra buildsystem expects the shared libs being part of the 
sources that are build, not being imported from the outside. There is no 
support for that.

So pruning is what you will need to do currently.

Cheers
Friedrich


packaging Calligra: common dependencies?

2016-12-25 Thread René J . V . Bertin
Hi,

Sorry in advance if I could have scraped this information from the build 
instructions:

I'm starting to look at creating MacPorts ports for Calligra (starting with 
Karbon). I see that it's possible to build and package a set of Calligra 
libraries and components shared among all or a major subset of components. 
That's great because with the MacPorts approach the build and packaging steps 
are linked, meaning it's not possible to build everything once and then 
generate packages for individual components.

But support I build and package LIB_CALLIGRA, LIB_KOMAIN and family on their 
own, how does this work out when building say Karbon or Kexi? Will the build 
system pick up the fact that the required dependencies are already installed, 
is their a way to instruct CMake that this is the case, or will I have to prune 
everything already installed from the package (during the "post-destroot", in 
MacPorts speak)?

The Calligra 2.9 port I made used a different approach with different 
installation variants corresponding to different product sets. This time I'd 
like to make it possible for users to decide exactly which of the supported 
applications they install or uninstall independently. That will also make it 
easier for me to concentrate on the different applications in turn without 
having to uninstall everything when I start adding support for a new Calligra 
application.

Thanks,
R.