Git migration for 2.0.0 + code components re-structuring...

[Gilles Caulier-4]

Hi all,

If you fell kde development mailing list thread, recently a lots of
project has started svn to git migration.

I think we can plan to do it with digiKam and kipi-plugins code 2.0.0,
and let's 1.x code to svn to be able to release bug-fixes only 1.8.0
and perhaps 1.9.0, as i plan here :

http://www.digikam.org/drupal/about/releaseplan

The disadvantage to move svn Gosc2010 branch to git is the difficulty
to synchronize with trunk code automatically. This is why after
digiKam 1.7.0, only small bug-fixes must be applied to 1.x code.

The documentation to process svn to git migration is here :

http://techbase.kde.org/Projects/MovetoGit

Andi, I remember that you have been volunteer in the past to process
git migration. Right ?

Other important point, if to restructure software components to
simplify life of developers, users, packagers.

A lots of peoples ask me to remove kdegraphics/libs dependency, which
increase complexity to upgrade these shared libraries in some cases.

The reasons why we share libraries is to solve common dependencies
between kipi-plugins and digiKam (libkdcraw and libkevix2)

Libkipi is more complex stuff because it's shared with others
photo-management softwares (gwenview, kphotoalbum)

Now, with 2.0.0, the complexity will be increased again with new
libkface and libkmap.

Why not to use Git migration to re-structure digiKam and kipi-plugins
components ?

This is my proposal : make a digiKam packaging including current
digiKam + kipi-plugins + libkface + libkmap. The root dir contents of
digiKam will become something like that :

digikam/
 \--cmake/
 \--data/
 \--databaseserver/
 \--digikam/
 \--imageplugins/
 \--kioslave/
 \--libs/
 \--project/
 \--showfoto/
 \--tests/
 \--themedesigner/
 \--utilities/
 \--kipi-plugins
 \--libkmap
 \--libkface

look 3 last line of this tree...

kipi-plugins will still undependant of digiKam core and installed as
well, as now. i18n rules still also the same.

About libkface, libkmap, it will work as kipi-plugins : it stand alone
shared librared installed on the system.

This will solve the huge puzzle for us, digiKam & co developpers. As
we maintain this code...

What do you think about ?

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Martin Klapetek]

On Thu, Dec 9, 2010 at 10:34, Gilles Caulier <[hidden email]> wrote:

About libkface, libkmap, it will work as kipi-plugins : it stand alone
shared librared installed on the system.

This will solve the huge puzzle for us, digiKam & co developpers. As
we maintain this code...

What do you think about ?

I agree to ship as many things as possible ourselves, or make them otherwise independent. Because then distro packagers have problems packaging it and users then end up with 1.2.0 in some recent distro and they are reporting bugs against 1.2.0 and we just reply to update to newer version and try again, but they actually can't, because thier distro doesn't package newer version, because of the libs being part of KDE trunk (and they don't package trunk stuff). So for the sake of the users, I think we should ship as many things as possible ourselves.

Marty

 

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

Martin,

this is exactly the purpose of my proposal, to create a digiKam
package including kipi-plugins and shared libs.

If the concept is fine, we can plan to host by the same way a forked
version of libkexiv2 and libkdcraw. For the moment it's not the goal.
We can life a little bits with kdegraphics/libs.

Only one library cannot not be shared like this : libkipi. Why?
because this one is shared with Kphotoalbum and gwenview.

Gilles

2010/12/9 Martin Klapetek <[hidden email]>:

>
> On Thu, Dec 9, 2010 at 10:34, Gilles Caulier <[hidden email]>
> wrote:
>>
>> About libkface, libkmap, it will work as kipi-plugins : it stand alone
>> shared librared installed on the system.
>>
>> This will solve the huge puzzle for us, digiKam & co developpers. As
>> we maintain this code...
>>
>> What do you think about ?
>
> I agree to ship as many things as possible ourselves, or make them otherwise
> independent. Because then distro packagers have problems packaging it and
> users then end up with 1.2.0 in some recent distro and they are reporting
> bugs against 1.2.0 and we just reply to update to newer version and try
> again, but they actually can't, because thier distro doesn't package newer

Thi sis > version, because of the libs being part of KDE trunk (and
they don't package

> trunk stuff). So for the sake of the users, I think we should ship as many
> things as possible ourselves.
> Marty
>
>>
>> Gilles Caulier
>> _______________________________________________
>> Digikam-devel mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

---------- Forwarded message ----------
From: Gilles Caulier <[hidden email]>
Date: 2010/12/9
Subject: Re: [Kde-imaging] Re: [Digikam-devel] Re: Git migration for
2.0.0 + code components re-structuring...
To: [hidden email]


2010/12/9 Angelo Naselli <[hidden email]>:
> giovedì 9 dicembre 2010 alle 15:49, Gilles Caulier ha scritto:
>> I know that Mandriva backport trunk/unstable but it's not the case of
>> debian ubuntu, and fedora, which won't to do work in this way. They
>> want to backport unstabilized code in all case. It's a logic goal...
> bah, logic? what's logic in having an unstable system if you're not e tester?
> I don't mean digikam is unstable, and anyway if someone wants to have last release
> of all in his distribution can always backports all he needs.

The logic is to always use stable version of kdegraphics/libs in a
distro. This is a right proff of quality.

Mixing unstable code with stable code from KDE core sound like
dangerous for packagers. This is what DEbian, Ubuntu and Fedora
packager said to me by private mail or in bugzilla.

Of course i tried to convince packagers that this unstable code can be
used in production but without any sucess.

As Martin said previously, this is not the better way to deal with
distro to force to include unstable code in production.

> I don't talk about mandriva, i just talk about a way of thinking (mine of course ;)).
>
>>Why not to try a digiKam package as explained before, without to fork
>>unstable libkexiv2, libkdcraw for the moment ? We can see if it's
>>work...
> We can move every libkxxx we need, but if we share one of them with
> someoneelse (kdegraphics for instance) we must take that in account.

yes of course...

But as i tried to explain before, the goal is not to remove libkexiv2
and libkdcraw from kdegraphics/libs.

The goal is to host the current unstable code from trunk in digiKam
package and use it with the digiKam and co release. This copy of
unstable code will have API/ABI id increased to be installed in both
to the system without to break anything.

The current stable will not be in conflict with unstable version. When
unstable become stable, we copy this code to next trunk KDE, and we
start new unstable with digiKam... Do you understand what i mean ?

> We cannot do what we want and we have to decide if depending on trunk
> ("unstable") or branch (should be stable).

sure, and i really at the good place to take a choice, but to convice
packagers it's another story... And i have don't much time to trying
to change policy of linux distro.
>
> Anyway deciding to move libkxxx from kdegraphics to digikam (or extragear,or...)
> should be decided also with all that projects that need them...

As i explain before, we will never remove these shared libs from
kdegraphics. For 3rd party applications which use it, nothing will
change.

Gilles
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

---------- Forwarded message ----------
From: Angelo Naselli <[hidden email]>
Date: 2010/12/9
Subject: [Kde-imaging] Re: [Digikam-devel] Re: Git migration for 2.0.0
+ code components re-structuring...
To: [hidden email]


giovedì 9 dicembre 2010 alle 15:49, Gilles Caulier ha scritto:
> I know that Mandriva backport trunk/unstable but it's not the case of
> debian ubuntu, and fedora, which won't to do work in this way. They
> want to backport unstabilized code in all case. It's a logic goal...
bah, logic? what's logic in having an unstable system if you're not e tester?
I don't mean digikam is unstable, and anyway if someone wants to have
last release
of all in his distribution can always backports all he needs.
I don't talk about mandriva, i just talk about a way of thinking (mine
of course ;)).

>Why not to try a digiKam package as explained before, without to fork
>unstable libkexiv2, libkdcraw for the moment ? We can see if it's
>work...
We can move every libkxxx we need, but if we share one of them with
someoneelse (kdegraphics for instance) we must take that in account.
We cannot do what we want and we have to decide if depending on trunk
("unstable") or branch (should be stable).

Anyway deciding to move libkxxx from kdegraphics to digikam (or extragear,or...)
should be decided also with all that projects that need them...

Just my 2 €cents
       Angelo

_______________________________________________
Kde-imaging mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/kde-imaging

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

Hi Gilles,

On 12/09/2010 10:34 AM, Gilles Caulier wrote:

> This is my proposal : make a digiKam packaging including current
> digiKam + kipi-plugins + libkface + libkmap. The root dir contents of
> digiKam will become something like that :
>
> digikam/
>   \--cmake/
>   \--data/
>   \--databaseserver/
>   \--digikam/
>   \--imageplugins/
>   \--kioslave/
>   \--libs/
>   \--project/
>   \--showfoto/
>   \--tests/
>   \--themedesigner/
>   \--utilities/
>   \--kipi-plugins
>   \--libkmap
>   \--libkface

I think this is a very good idea! However, I would propose one change:
How about we add a directory 'guests' where one can optionally place
libkexiv2, libkdcraw, etc., if one wants to compile them along with
digikam, and then digikam can use the versions in 'guests' instead of
the system-supplied ones. This would make it easier for users to compile
digikam, because they just checkout digikam, go to guests directory,
checkout libkexiv2, libkdcraw, and compile digikam along with them.

Michael
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[kunal ghosh]

On Thu, Dec 9, 2010 at 5:01 PM, Gilles Caulier <[hidden email]> wrote:

Martin,

this is exactly the purpose of my proposal, to create a digiKam
package including kipi-plugins and shared libs.

If the concept is fine, we can plan to host by the same way a forked
version of libkexiv2 and libkdcraw. For the moment it's not the goal.
We can life a little bits with kdegraphics/libs.

With git we can use git hooks , these are small shell scripts which get executed 

based on some git event . eg. before git-push , after git-rebase etc.

We can pull in from the different places using a hook, that

should abstract some of the (pulling from different places)

and also prevent forking.

http://www.kernel.org/pub/software/scm/git/docs/githooks.html

 

Only one library cannot not be shared like this : libkipi. Why?
because this one is shared with Kphotoalbum and gwenview.

Gilles

2010/12/9 Martin Klapetek <[hidden email]>:

>
> On Thu, Dec 9, 2010 at 10:34, Gilles Caulier <[hidden email]>
> wrote:
>>
>> About libkface, libkmap, it will work as kipi-plugins : it stand alone
>> shared librared installed on the system.
>>
>> This will solve the huge puzzle for us, digiKam & co developpers. As
>> we maintain this code...
>>
>> What do you think about ?
>
> I agree to ship as many things as possible ourselves, or make them otherwise
> independent. Because then distro packagers have problems packaging it and
> users then end up with 1.2.0 in some recent distro and they are reporting
> bugs against 1.2.0 and we just reply to update to newer version and try
> again, but they actually can't, because thier distro doesn't package newer

Thi sis > version, because of the libs being part of KDE trunk (and

they don't package
> trunk stuff). So for the sake of the users, I think we should ship as many
> things as possible ourselves.
> Marty
>
>>
>> Gilles Caulier
>> _______________________________________________
>> Digikam-devel mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>
> _______________________________________________
> Digikam-devel mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
>

_______________________________________________
Kde-imaging mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/kde-imaging

--
regards
-------
Kunal Ghosh
Dept of Computer Sc. & Engineering.
Sir MVIT
Bangalore,India

Blog:kunalghosh.wordpress.com
Website:www.kunalghosh.net46.net

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

There is also this page which can be important to know about Git migration :

http://techbase.kde.org/Development/Tutorials/Git

Gilles Caulier

2010/12/9 Gilles Caulier <[hidden email]>:

> Hi all,
>
> If you fell kde development mailing list thread, recently a lots of
> project has started svn to git migration.
>
> I think we can plan to do it with digiKam and kipi-plugins code 2.0.0,
> and let's 1.x code to svn to be able to release bug-fixes only 1.8.0
> and perhaps 1.9.0, as i plan here :
>
> http://www.digikam.org/drupal/about/releaseplan
>
> The disadvantage to move svn Gosc2010 branch to git is the difficulty
> to synchronize with trunk code automatically. This is why after
> digiKam 1.7.0, only small bug-fixes must be applied to 1.x code.
>
> The documentation to process svn to git migration is here :
>
> http://techbase.kde.org/Projects/MovetoGit
>
> Andi, I remember that you have been volunteer in the past to process
> git migration. Right ?
>
> Other important point, if to restructure software components to
> simplify life of developers, users, packagers.
>
> A lots of peoples ask me to remove kdegraphics/libs dependency, which
> increase complexity to upgrade these shared libraries in some cases.
>
> The reasons why we share libraries is to solve common dependencies
> between kipi-plugins and digiKam (libkdcraw and libkevix2)
>
> Libkipi is more complex stuff because it's shared with others
> photo-management softwares (gwenview, kphotoalbum)
>
> Now, with 2.0.0, the complexity will be increased again with new
> libkface and libkmap.
>
> Why not to use Git migration to re-structure digiKam and kipi-plugins
> components ?
>
> This is my proposal : make a digiKam packaging including current
> digiKam + kipi-plugins + libkface + libkmap. The root dir contents of
> digiKam will become something like that :
>
> digikam/
>  \--cmake/
>  \--data/
>  \--databaseserver/
>  \--digikam/
>  \--imageplugins/
>  \--kioslave/
>  \--libs/
>  \--project/
>  \--showfoto/
>  \--tests/
>  \--themedesigner/
>  \--utilities/
>  \--kipi-plugins
>  \--libkmap
>  \--libkface
>
> look 3 last line of this tree...
>
> kipi-plugins will still undependant of digiKam core and installed as
> well, as now. i18n rules still also the same.
>
> About libkface, libkmap, it will work as kipi-plugins : it stand alone
> shared librared installed on the system.
>
> This will solve the huge puzzle for us, digiKam & co developpers. As
> we maintain this code...
>
> What do you think about ?
>
> Gilles Caulier
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

I propose a better code dir re-structuring : a lead
"digikam" root folder, including a "core" dir hosting current root
digikam dir. All other guest codes still on root "digikam" folder.

digikam/
    \--kipi-plugins
    \--libkmap
    \--libkface
    \--core/
           \--cmake/
           \--data/
           \--databaseserver/
           \--digikam/
           \--imageplugins/
           \--kioslave/
           \--libs/
           \--project/
           \--showfoto/
           \--tests/
           \--themedesigner/
           \--utilities/

like this, to synchronize digikam as well with a separate branch, it's
more easy. all is in core sub-dir.

your viewpoints ?

Gilles Caulier

2010/12/9 Gilles Caulier <[hidden email]>:

> Hi all,
>
> If you fell kde development mailing list thread, recently a lots of
> project has started svn to git migration.
>
> I think we can plan to do it with digiKam and kipi-plugins code 2.0.0,
> and let's 1.x code to svn to be able to release bug-fixes only 1.8.0
> and perhaps 1.9.0, as i plan here :
>
> http://www.digikam.org/drupal/about/releaseplan
>
> The disadvantage to move svn Gosc2010 branch to git is the difficulty
> to synchronize with trunk code automatically. This is why after
> digiKam 1.7.0, only small bug-fixes must be applied to 1.x code.
>
> The documentation to process svn to git migration is here :
>
> http://techbase.kde.org/Projects/MovetoGit
>
> Andi, I remember that you have been volunteer in the past to process
> git migration. Right ?
>
> Other important point, if to restructure software components to
> simplify life of developers, users, packagers.
>
> A lots of peoples ask me to remove kdegraphics/libs dependency, which
> increase complexity to upgrade these shared libraries in some cases.
>
> The reasons why we share libraries is to solve common dependencies
> between kipi-plugins and digiKam (libkdcraw and libkevix2)
>
> Libkipi is more complex stuff because it's shared with others
> photo-management softwares (gwenview, kphotoalbum)
>
> Now, with 2.0.0, the complexity will be increased again with new
> libkface and libkmap.
>
> Why not to use Git migration to re-structure digiKam and kipi-plugins
> components ?
>
> This is my proposal : make a digiKam packaging including current
> digiKam + kipi-plugins + libkface + libkmap. The root dir contents of
> digiKam will become something like that :
>
> digikam/
>  \--cmake/
>  \--data/
>  \--databaseserver/
>  \--digikam/
>  \--imageplugins/
>  \--kioslave/
>  \--libs/
>  \--project/
>  \--showfoto/
>  \--tests/
>  \--themedesigner/
>  \--utilities/
>  \--kipi-plugins
>  \--libkmap
>  \--libkface
>
> look 3 last line of this tree...
>
> kipi-plugins will still undependant of digiKam core and installed as
> well, as now. i18n rules still also the same.
>
> About libkface, libkmap, it will work as kipi-plugins : it stand alone
> shared librared installed on the system.
>
> This will solve the huge puzzle for us, digiKam & co developpers. As
> we maintain this code...
>
> What do you think about ?
>
> Gilles Caulier
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[kunal ghosh]

On 12/11/2010 05:41 PM, Angelo Naselli wrote:

In data sabato 11 dicembre 2010 08:15:33, Gilles Caulier ha scritto:

I propose a better code dir re-structuring : a lead
"digikam" root folder, including a "core" dir hosting current root
digikam dir. All other guest codes still on root "digikam" folder.

digikam/
    \--kipi-plugins
    \--libkmap
    \--libkface
    \--core/
           \--cmake/
           \--data/
           \--databaseserver/
           \--digikam/
           \--imageplugins/
           \--kioslave/
           \--libs/
           \--project/
           \--showfoto/
           \--tests/
           \--themedesigner/
           \--utilities/

I like both the structures suggested.
for better clarity we could group { kipi-plugins, libkmap, libkface }
into a separate sub-directory.

like so,

digikam/
    \--build_deps/ 
    	\--kipi-plugins
	\--libkmap
	\--libkface
    \--digikam_core/
           \--cmake/
           \--data/
           \--databaseserver/
           \--digikam/
           \--imageplugins/
           \--kioslave/
           \--libs/
           \--project/
           \--showfoto/
           \--tests/
           \--themedesigner/
           \--utilities/

like this, to synchronize digikam as well with a separate branch, it's
more easy. all is in core sub-dir.

your viewpoints ?

how about nex one? 
digikam/
\--3d-party
	\--kipi-plugins
	\--libkmap
	\--libkface
\--cmake/
\--data/
\--databaseserver/
\--digikam/
\--imageplugins/
\--kioslave/
\--libs/
\--project/
\--showfoto/
\--tests/
\--themedesigner/
\--utilities/

3d party is optional and to be used in developing for the most.

_______________________________________________
Kde-imaging mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/kde-imaging

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

yes, right.

But i already worklike this on my system. both, official package and
devel libraries are installed in /usr. there is not conflicts because
ABI and API are increased into devel. libraries soname are not the
same. I think it's work fine.

I will prepare svn GoSC2010 branche like this and let's you test in
your computer to see if all i fine. Especially, if options that i will
add to cmake will be fine to compile/install 3rdparty components
independantly and digiKam as stand alone, using shared libs provided
by the system.

 Marcel, Michael,

I will move back libkmap and libkface from kdereview to GoSC2010
branch today to prepare 2.0.0 source code using this schema.

also, the time to lets libkmap and libkface have been enough i think...

Later, if we want to share this libraries at the right place to kde
core, we can do it as well to copy 3rdparty folder on kde components.

Gilles

2010/12/11 Angelo Naselli <[hidden email]>:

> In data giovedì 9 dicembre 2010 18:18:19, Gilles Caulier ha scritto:
>> The goal is to host the current unstable code from trunk in digiKam
>> package and use it with the digiKam and co release. This copy of
>> unstable code will have API/ABI id increased to be installed in both
>> to the system without to break anything.
> You need to take care also that the version you release out of trunk
> *have* to be upgraded by the next trunk (e.g. kdegraphics stable) version
> to avoid conflicts.
> Remember that a system that installs libfoo from a standalone package
> can have conflicts when updates libfoo using another package.
> I mean libkipi-kdegraphics and libkipi-standalone are in conflicts if
> they produce same files in same position...
> And certainly packager have to take in account the developer
> version of that library...
>
> Cheers,
> --
>        Angelo
>
> _______________________________________________
> Kde-imaging mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/kde-imaging
>
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

All move are done with commit #1205541.

Please checkout source code in GoSC2010 branch :

http://websvn.kde.org/branches/extragear/graphics/digikam/

I will prepare all lead CMakeList.txt files

Gilles Caulier

2010/12/11 Gilles Caulier <[hidden email]>:

> yes, right.
>
> But i already worklike this on my system. both, official package and
> devel libraries are installed in /usr. there is not conflicts because
> ABI and API are increased into devel. libraries soname are not the
> same. I think it's work fine.
>
> I will prepare svn GoSC2010 branche like this and let's you test in
> your computer to see if all i fine. Especially, if options that i will
> add to cmake will be fine to compile/install 3rdparty components
> independantly and digiKam as stand alone, using shared libs provided
> by the system.
>
>  Marcel, Michael,
>
> I will move back libkmap and libkface from kdereview to GoSC2010
> branch today to prepare 2.0.0 source code using this schema.
>
> also, the time to lets libkmap and libkface have been enough i think...
>
> Later, if we want to share this libraries at the right place to kde
> core, we can do it as well to copy 3rdparty folder on kde components.
>
> Gilles
>
> 2010/12/11 Angelo Naselli <[hidden email]>:
>> In data giovedì 9 dicembre 2010 18:18:19, Gilles Caulier ha scritto:
>>> The goal is to host the current unstable code from trunk in digiKam
>>> package and use it with the digiKam and co release. This copy of
>>> unstable code will have API/ABI id increased to be installed in both
>>> to the system without to break anything.
>> You need to take care also that the version you release out of trunk
>> *have* to be upgraded by the next trunk (e.g. kdegraphics stable) version
>> to avoid conflicts.
>> Remember that a system that installs libfoo from a standalone package
>> can have conflicts when updates libfoo using another package.
>> I mean libkipi-kdegraphics and libkipi-standalone are in conflicts if
>> they produce same files in same position...
>> And certainly packager have to take in account the developer
>> version of that library...
>>
>> Cheers,
>> --
>>        Angelo
>>
>> _______________________________________________
>> Kde-imaging mailing list
>> [hidden email]
>> https://mail.kde.org/mailman/listinfo/kde-imaging
>>
>>
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

"3rdparty" => "extra"

Fine for you ?

Gilles

2010/12/11 Marcel Wiesweg <[hidden email]>:

>
>> yes, 3rdparty is fine.
>
> 3rdparty is a bit misleading, because in fact it's not 3rd party code, but our
> own, just a separate module. It also buries the kipi-plugins in some directory
> which is easily ignored.
>
> digikam/
>    \--kipi-plugins
>    \--libkmap
>    \--libkface
>    \--core/ (or digikam/, or application/)
>
> would emphasize that these modules are still somewhat independent, and that
> they dont depend on digikamcore in any way.
>
> Marcel
> _______________________________________________
> Kde-imaging mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/kde-imaging
>

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

Hi Gilles,

On 12/11/2010 01:51 PM, Gilles Caulier wrote:
 > All move are done with commit #1205541.
 >
 > Please checkout source code in GoSC2010 branch :
 >
 > http://websvn.kde.org/branches/extragear/graphics/digikam/
 >
 > I will prepare all lead CMakeList.txt files

I like this structure and will try to test it later. Maybe we should
also add a README to the root directory?

Michael


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

On 12/12/2010 02:47 PM, Michael G. Hansen wrote:

> Hi Gilles,
>
> On 12/11/2010 01:51 PM, Gilles Caulier wrote:
>   >  All move are done with commit #1205541.
>   >
>   >  Please checkout source code in GoSC2010 branch :
>   >
>   >  http://websvn.kde.org/branches/extragear/graphics/digikam/
>   >
>   >  I will prepare all lead CMakeList.txt files
>
> I like this structure and will try to test it later. Maybe we should
> also add a README to the root directory?

I checked out the new structure and tried to compile it. I first
uninstalled libkmap, libkface and libkdcraw which used to be compiled
separately. Then the build failed:

< some stuff removed here >
-- Found Qt-Version 4.7.0 (using /usr/local/bin/qmake)
-- Found X11: /usr/lib/libX11.so
-- Found KDE 4.6 include dir: /usr/local/include
-- Found KDE 4.6 library dir: /usr/local/lib
-- Found the KDE4 kconfig_compiler preprocessor:
/usr/local/bin/kconfig_compiler
-- Found automoc4: /usr/local/bin/automoc4
-- Found Kexiv2 library in cache: /usr/local/lib/libkexiv2.so
-- Check Kdcraw library in local sub-folder...
-- Check Kdcraw library using pkg-config...
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig
-- PKGCONFIG() indicates that libkdcraw is not installed (install the
package which contains libkdcraw.pc if you want to support this feature)
CMake Error at /usr/local/share/apps/cmake/modules/FindKdcraw.cmake:98
(message):
   Could NOT find libkdcraw header files
Call Stack (most recent call first):
   3rdparty/kipi-plugins/CMakeLists.txt:116 (FIND_PACKAGE)


-- Configuring incomplete, errors occurred!

So I re-installed libkdcraw, and then the build failed because FindKMap
was not found:

--  libkmap library found.................... NO
--
CMake Error at 3rdparty/kipi-plugins/CMakeLists.txt:85 (MESSAGE):
    kipi-plugins needs libkmap. You need to install the libkmap (version
 >= 0.1.0) library development package.
Call Stack (most recent call first):
   3rdparty/kipi-plugins/CMakeLists.txt:184 (PRINT_LIBRARY_STATUS)


--  libkmap website is at http://www.digikam.org/sharedlibs
--

The same problem appears for libkface, if you install libkmap.

Michael


_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

On 12/12/2010 05:03 PM, Michael G. Hansen wrote:

> On 12/12/2010 02:47 PM, Michael G. Hansen wrote:
>> Hi Gilles,
>>
>> On 12/11/2010 01:51 PM, Gilles Caulier wrote:
>>    >   All move are done with commit #1205541.
>>    >
>>    >   Please checkout source code in GoSC2010 branch :
>>    >
>>    >   http://websvn.kde.org/branches/extragear/graphics/digikam/
>>    >
>>    >   I will prepare all lead CMakeList.txt files
>>
>> I like this structure and will try to test it later. Maybe we should
>> also add a README to the root directory?
>
> I checked out the new structure and tried to compile it. I first
> uninstalled libkmap, libkface and libkdcraw which used to be compiled
> separately. Then the build failed:

I modified the FindXXX.cmake files to find the local versions, now the
build works fine for me. The FindKdcraw.cmake file is a copy of the one
from kdelibs, which should be merged back at some point.

Michael
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

>>> I like this structure and will try to test it later. Maybe we should
>>> also add a README to the root directory?
>>
>> I checked out the new structure and tried to compile it. I first
>> uninstalled libkmap, libkface and libkdcraw which used to be compiled
>> separately. Then the build failed:
>
> I modified the FindXXX.cmake files to find the local versions, now the
> build works fine for me. The FindKdcraw.cmake file is a copy of the one
> from kdelibs, which should be merged back at some point.

I get several CMake warnings like
-- Configuring done
CMake Warning at c:/KDE/share/apps/cmake/modules/KDE4Macros.cmake:933
(add_executable):
  Cannot generate a safe linker search path for target libkmap_demo because
  there is a cycle in the constraint graph:

    dir 0 is [C:/KDE/lib]
      dir 1 must precede it due to link library [libkmap.dll.a]
    dir 1 is [C:/KdeDevel/GoSC2010/digikam/build/bin]
      dir 2 must precede it due to link library [libkexiv2.dll.a]
    dir 2 is [c:/KDE/lib]
      dir 1 must precede it due to link library [libkmap.dll.a]
    dir 3 is [C:/kde/lib]
      dir 1 must precede it due to link library [libkmap.dll.a]

  Some of these libraries may not be found correctly.
Call Stack (most recent call first):
  extra/libkmap/demo/CMakeLists.txt:37 (KDE4_ADD_EXECUTABLE)

It seems "funny" that some of those libs are found from c:/KDE/lib,
they are all built together and installed only later. Aren't they?

Perhaps it is because the "find*.cmake" do not take account that
libraries have moved from "libs" subfolder into "extra" one? Patch to
find "extra" ones also included for some libs. If the way to jadnle
this is good I can make patch for other libs also.

Gert

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Michael G. Hansen]

Hi Gert,

On 12/13/2010 05:03 PM, Gert Kello wrote:

>>>> I like this structure and will try to test it later. Maybe we should
>>>> also add a README to the root directory?
>>>
>>> I checked out the new structure and tried to compile it. I first
>>> uninstalled libkmap, libkface and libkdcraw which used to be compiled
>>> separately. Then the build failed:
>>
>> I modified the FindXXX.cmake files to find the local versions, now the
>> build works fine for me. The FindKdcraw.cmake file is a copy of the one
>> from kdelibs, which should be merged back at some point.
>
> I get several CMake warnings like
> -- Configuring done
> CMake Warning at c:/KDE/share/apps/cmake/modules/KDE4Macros.cmake:933
> (add_executable):
>    Cannot generate a safe linker search path for target libkmap_demo because
>    there is a cycle in the constraint graph:
>
>      dir 0 is [C:/KDE/lib]
>        dir 1 must precede it due to link library [libkmap.dll.a]
>      dir 1 is [C:/KdeDevel/GoSC2010/digikam/build/bin]
>        dir 2 must precede it due to link library [libkexiv2.dll.a]
>      dir 2 is [c:/KDE/lib]
>        dir 1 must precede it due to link library [libkmap.dll.a]
>      dir 3 is [C:/kde/lib]
>        dir 1 must precede it due to link library [libkmap.dll.a]
>
>    Some of these libraries may not be found correctly.
> Call Stack (most recent call first):
>    extra/libkmap/demo/CMakeLists.txt:37 (KDE4_ADD_EXECUTABLE)
>
> It seems "funny" that some of those libs are found from c:/KDE/lib,
> they are all built together and installed only later. Aren't they?

I had these problems before fixing the the FindXXX.cmake files when
libkexiv2 was already installed. Maybe you could update to the latest
version, where I fixed the FindKexiv2 and FindKipi files. You may want
to clear the CMakeCache.txt file to make sure all libraries are found
properly.

> Perhaps it is because the "find*.cmake" do not take account that
> libraries have moved from "libs" subfolder into "extra" one? Patch to
> find "extra" ones also included for some libs. If the way to jadnle
> this is good I can make patch for other libs also.

Thanks for the patch, but I inserted the more general version that I
made for FindKMap, because it allows the host application to specify a
local directory, so we don't have to patch all FindXXX files when we
decide on a new directory structure ;-)

Michael
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

It still a problem with OpenCV detection into kipi-plugins :

-- ----------------------------------------------------------------------------------
-- Starting CMake configuration for: kipi-plugins
-- Found Qt-Version 4.6.2 (using /usr/lib/qt4/bin/qmake)
-- Found X11: /usr/lib/libX11.so
-- Phonon Version: 4.4.1
-- Found KDE 4.4 include dir: /usr/include
-- Found KDE 4.4 library dir: /usr/lib
-- Found the KDE4 kconfig_compiler preprocessor: /usr/bin/kconfig_compiler
-- Found automoc4: /usr/bin/automoc4
-- Check Kexiv2 library in local sub-folder...
-- Found Kexiv2 library in local sub-folder:
/mnt/data/Devel/SVN/branches/digikam/extra/libkexiv2
-- Check Kdcraw library in local sub-folder...
-- Found Kdcraw library in local sub-folder:
/mnt/data/Devel/SVN/branches/digikam/extra/libkdcraw
-- Check Kipi library in local sub-folder...
-- Found Kipi library in local sub-folder:
/mnt/data/Devel/SVN/branches/digikam/extra/libkipi
-- Check Kmap library in local sub-folder...
-- Found Kmap library in local sub-folder:
/mnt/data/Devel/SVN/branches/digikam/extra/libkmap
-- Found JPEG: /usr/lib/libjpeg.so
-- Found ZLIB: /usr/lib/libz.so
-- Found PNG: /usr/lib/libpng.so
-- Found TIFF: /usr/lib/libtiff.so
-- Found EXPAT: /usr/lib/libexpat.so
--   found libxml-2.0, version 2.7.7
-- Found LibXml2: /usr/lib/libxml2.so
--   found libxslt, version 1.1.26
-- Found LibXslt: /usr/lib/libxslt.so
-- checking for module 'libgpod-1.0'
--   found libgpod-1.0, version 0.7.93
-- Found Gpod: /usr/include/gpod-1.0
-- checking for module 'gdk-pixbuf-2.0'
--   found gdk-pixbuf-2.0, version 2.20.1
-- Found Gdk: /usr/include/gtk-2.0
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig
-- Found GLIB2: /usr/lib/libglib-2.0.so
-- checking for module 'gobject-2.0'
--   found gobject-2.0, version 2.24.1
-- Found GObject libraries:
/usr/lib/libgobject-2.0.so;/usr/lib/libgmodule-2.0.so;/usr/lib/libgthread-2.0.so;/usr/lib/libglib-2.0.so
-- Found GObject includes : /usr/include/glib-2.0/gobject
-- Found KdepimLibs: /usr/lib/cmake/KdepimLibs/KdepimLibsConfig.cmake
--   found qca2, version 2.0.2
-- Found QCA2: /usr/lib/libqca.so
-- Found libksane: /usr/lib/libksane.so
-- Checking GNUCXX version 3/4 to determine  OpenCV /opt/net/ path
-- checking for module 'QJson>=0.5'
--   found QJson, version 0.6.0
-- Found QJSON: qjson;QtCore
-- Found X11: /usr/lib/libX11.so
-- CMake version: cmake version 2.8.1

-- CMake version (cleaned): cmake version 2.8.1

--
-- ----------------------------------------------------------------------------------
--  kipi-plugins 2.0.0-GoSC2010 dependencies results
<http://www.kipi-plugins.org>
--
--  libjpeg library found.................... YES
--  libtiff library found.................... YES
--  libpng library found..................... YES
--  libkipi library found.................... YES
--  libkexiv2 library found.................. YES
--  libkdcraw library found.................. YES
--  libkmap library found.................... YES
--  libxml2 library found.................... YES (optional)
--  libxslt library found.................... YES (optional)
--  libexpat library found................... YES (optional)
--  native threads support library found..... YES (optional)
--  libopengl library found.................. YES (optional)
--  Qt4 OpenGL module found.................. YES
--  libopencv library found.................. NO  (optional)
--  QJson library found...................... YES (optional)
--  libgpod library found.................... YES (optional)
--  Gdk library found........................ YES (optional)
--  libkdepim library found.................. YES (optional)
--  qca2 library found....................... YES (optional)
--  OpenMP library found..................... YES (optional)
--  libX11 library found..................... YES (optional)
--  libksane library found................... YES (optional)
--
--  kipi-plugins will be compiled............ YES
--  Shwup will be compiled................... YES (optional)
--  HtmlExport will be compiled.............. YES (optional)
--  AdvancedSlideshow will be compiled....... YES (optional)
--  ImageViewer will be compiled............. YES (optional)
--  AcquireImages will be compiled........... YES (optional)
--  DNGConverter will be compiled............ YES (optional)
--  RemoveRedEyes will be compiled........... NO  (optional - Look
README file for more details about dependencies)
--  Debian Screenshots will be compiled...... YES (optional)
--  IpodExport will be compiled.............. YES (optional)
--  Calendar will be compiled................ YES (optional)
-- ----------------------------------------------------------------------------------

OpenCV is detected with libkface (find cmake script is there), but
kipi-plugins is not able to use it. Why ?

Gilles Caulier
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

> I had these problems before fixing the the FindXXX.cmake files when
> libkexiv2 was already installed. Maybe you could update to the latest
> version, where I fixed the FindKexiv2 and FindKipi files. You may want
> to clear the CMakeCache.txt file to make sure all libraries are found
> properly.

Yes, latest version did work fine.

Just this OpenCV problems:
1. FindOpenCV.cmake included with libkface is not able to find it. If
I delete it then OpenCV is found
2. I have to make a little modification to
Index: libkface/libkface/CMakeLists.txt
===================================================================
--- kdereview/libkface/libkface/CMakeLists.txt (revision 1202545)
+++ kdereview/libkface/libkface/CMakeLists.txt (working copy)
@@ -49,7 +49,7 @@
                             ${KDE4_KDEUI_LIBS}
                             ${QT_QTGUI_LIBRARY}
                             ${LIBFACE_LIBRARIES}
-                            ${OpenCV_LIBRARIES}
+                            ${OpenCV_LIBS}
                             )

 SET_TARGET_PROPERTIES(kface PROPERTIES VERSION ${KFACE_LIB_SO_VERSION_STRING}

3. kipi-plugins is not able to find OpenCV.

Gert
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel