current git compile fixes on OS X

[brad]

digikam-devs,

i'm trying to get back into digikam code and i have a couple of fixes needed
for compilation on OS X. They are pretty straightforward changes. os x uses
clang, i'm not sure if this is the reason for the changes. I find it odd that i
needed to add includes, but it seems to work this way, so far.

summary of changes:
 * digikam-sc/extra/kipi-plugins/dlnaexport/extra/hupnp/src/devicehosting/devicehost/hpresence_announcer_p.h
    +#include "hdevicehost_ssdp_handler_p.h"
 * digikam-sc/extra/kipi-plugins/dlnaexport/extra/hupnp/src/devicemodel/client/hclientadapterop.h
    +#include <QString>

 * digikam-sc/extra/kipi-plugins/CMakeLists.txt
    -    IF(FLEX_FOUND AND BISON_FOUND)
    +    IF(FLEX_FOUND AND BISON_FOUND AND FLEX_TARGET AND BISON_TARGET)


The last change is needed because the cmake modules installed through
MacPorts must be a little old so the FLEX_TARGET and BISON_TARGET marcos are
not defined whereas the FLEX_FOUND and BISON_FOUND are defined; so cmake will
eventually fail when trying to use FLEX_TAGET and BISON_TARGET marcos.

There are more changes that will likely come, but i haven't been able to
compile all of digikam yet as i keep on get undefined symbols when using the
internal liblqr source. Anyone get the internal version of liblqr compiling w/
clang on linux?

Thanks and cheers,
 -- brad


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

[Gilles Caulier-4]

2013/1/10 <[hidden email]>

digikam-devs,

i'm trying to get back into digikam code and i have a couple of fixes needed
for compilation on OS X. They are pretty straightforward changes. os x uses
clang, i'm not sure if this is the reason for the changes. I find it odd that i
needed to add includes, but it seems to work this way, so far.

summary of changes:
 * digikam-sc/extra/kipi-plugins/dlnaexport/extra/hupnp/src/devicehosting/devicehost/hpresence_announcer_p.h
    +#include "hdevicehost_ssdp_handler_p.h"
 * digikam-sc/extra/kipi-plugins/dlnaexport/extra/hupnp/src/devicemodel/client/hclientadapterop.h
    +#include <QString>

This is Hupnp library code usual patches. I will commit this and report back this info to library developpers...

 

 * digikam-sc/extra/kipi-plugins/CMakeLists.txt
    -    IF(FLEX_FOUND AND BISON_FOUND)
    +    IF(FLEX_FOUND AND BISON_FOUND AND FLEX_TARGET AND BISON_TARGET)

The last change is needed because the cmake modules installed through
MacPorts must be a little old so the FLEX_TARGET and BISON_TARGET marcos are
not defined whereas the FLEX_FOUND and BISON_FOUND are defined; so cmake will
eventually fail when trying to use FLEX_TAGET and BISON_TARGET marcos.

 

This is the recent changes for Panorama tools does by Benjamin Girault. I will CC him to review it (i'm not sure that he is in this ML)

 

 

There are more changes that will likely come, but i haven't been able to
compile all of digikam yet as i keep on get undefined symbols when using the
internal liblqr source. Anyone get the internal version of liblqr compiling w/
clang on linux?

this lib must be available through Macports normally. I don't touch to MAC env. since few month...

Feel free to provide more MAC feedbacks. It's always good to receive compatibility patches

Best

Gilles Caulier

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

[Gilles Caulier-4]

2013/1/10 <[hidden email]>

digikam-devs,

i'm trying to get back into digikam code and i have a couple of fixes needed
for compilation on OS X. They are pretty straightforward changes. os x uses
clang, i'm not sure if this is the reason for the changes. I find it odd that i
needed to add includes, but it seems to work this way, so far.

summary of changes:
 * digikam-sc/extra/kipi-plugins/dlnaexport/extra/hupnp/src/devicehosting/devicehost/hpresence_announcer_p.h
    +#include "hdevicehost_ssdp_handler_p.h"
 * digikam-sc/extra/kipi-plugins/dlnaexport/extra/hupnp/src/devicemodel/client/hclientadapterop.h
    +#include <QString>

Fixed : http://commits.kde.org/kipi-plugins/32c94aa2b64aa979593a12457e4a7c31f2c7eb96

Gilles Caulier

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

[Benjamin Girault]

Hi,

2013/1/11 Gilles Caulier <[hidden email]>:

>
> 2013/1/10 <[hidden email]>
>>
>>  * digikam-sc/extra/kipi-plugins/CMakeLists.txt
>>     -    IF(FLEX_FOUND AND BISON_FOUND)
>>     +    IF(FLEX_FOUND AND BISON_FOUND AND FLEX_TARGET AND BISON_TARGET)
>>
>>
>> The last change is needed because the cmake modules installed through
>> MacPorts must be a little old so the FLEX_TARGET and BISON_TARGET marcos
>> are
>> not defined whereas the FLEX_FOUND and BISON_FOUND are defined; so cmake
>> will
>> eventually fail when trying to use FLEX_TAGET and BISON_TARGET marcos.
>>
>
> This is the recent changes for Panorama tools does by Benjamin Girault. I
> will CC him to review it (i'm not sure that he is in this ML)

I am receiving emails from the ml digikam-dev.

About the CMakeLists.txt, it looks like a bug in FindFLEX.cmake and
FindBISON.cmake on MacOS. My opinion is that this patch is safe.

One question though: which version of cmake are you using? This is
important because the two previous files are installed by cmake.

Best,

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

[brad]

> > There are more changes that will likely come, but i haven't been able to
> > compile all of digikam yet as i keep on get undefined symbols when using
> > the
> > internal liblqr source. Anyone get the internal version of liblqr
> > compiling w/
> > clang on linux?
>
> this lib must be available through Macports normally. I don't touch to MAC
> env. since few month...
>

It is in macports. eventually was able to compile it successfully using the
library in macports; so i will also update the readme.macosx at some point.

I will still try to resolve the linking error when the internal version of
liblqr is used, it just makes sense to have it working everywhere, if
possible.

cheers,
 - brad



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

[brad]

On Jan 11, 2013, at 3:59 AM, Benjamin Girault <[hidden email]> wrote:

Hi,

2013/1/11 Gilles Caulier <[hidden email]>:

2013/1/10 <[hidden email]>

* digikam-sc/extra/kipi-plugins/CMakeLists.txt
   -    IF(FLEX_FOUND AND BISON_FOUND)
   +    IF(FLEX_FOUND AND BISON_FOUND AND FLEX_TARGET AND BISON_TARGET)


The last change is needed because the cmake modules installed through
MacPorts must be a little old so the FLEX_TARGET and BISON_TARGET marcos
are
not defined whereas the FLEX_FOUND and BISON_FOUND are defined; so cmake
will
eventually fail when trying to use FLEX_TAGET and BISON_TARGET marcos.

This is the recent changes for Panorama tools does by Benjamin Girault. I
will CC him to review it (i'm not sure that he is in this ML)

I am receiving emails from the ml digikam-dev.

About the CMakeLists.txt, it looks like a bug in FindFLEX.cmake and
FindBISON.cmake on MacOS. My opinion is that this patch is safe.

One question though: which version of cmake are you using? This is
important because the two previous files are installed by cmake.

Benjamin -- just updated to cmake 2.8.10 from macports. I looked at the situation in more detail; here's what's happening. 

There are two FindFlex.cmake files installed using macports, one from the cmake package (/opt/local/share/cmake-2.8/modules) and one from kdelibs4 package (/opt/local/share/cmake/modules).

For some reason cmake is always using the the one installed by the kdelibs4 package and not the one from the cmake package even if i list the cmake modules directory first with the -DCMAKE_MODULE_PATH argument. I'm not a cmake guru so i might be doing something wrong. I put a FATAL_WARNING in the kde FindFlex.cmake file to get a call stack and i got the following:

CMake Error at /opt/local/share/apps/cmake/modules/FindFLEX.cmake:17 (message):
  Using kdelibs flex.cmake
Call Stack (most recent call first):
  /opt/local/share/apps/cmake/modules/MacroOptionalFindPackage.cmake:32 (find_package)
  extra/kipi-plugins/CMakeLists.txt:169 (MACRO_OPTIONAL_FIND_PACKAGE)

If i move the FindFlex.cmake file provided by kdelibs out of the way, cmake runs fine. 

I'm not sure how to solve this cleanly at the moment w/o pano being disabled on osx since cmake will never use the proper FineFlex.cmake file. it seems that the proper solution would be to remove the FindFlex.cmake file form kdelibs since it appears to be distributed with cmake anyway. i don't know who controls the distribution files of kdelibs. 

Cheers,

 -- brad

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

[Gilles Caulier-4]

It is in macports. eventually was able to compile it successfully using the
library in macports; so i will also update the readme.macosx at some point.

I will still try to resolve the linking error when the internal version of
liblqr is used, it just makes sense to have it working everywhere, if
possible.

ok. Fell free to make a patch against git/master. I will apply it before 3.0.0 release date

Gilles Caulier

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

[Benjamin Girault]

2013/1/12  <[hidden email]>:
> Benjamin -- just updated to cmake 2.8.10 from macports. I looked at the
> situation in more detail; here's what's happening.

Same version here.

> There are two FindFlex.cmake files installed using macports, one from the
> cmake package (/opt/local/share/cmake-2.8/modules) and one from kdelibs4
> package (/opt/local/share/cmake/modules).
> For some reason cmake is always using the the one installed by the kdelibs4
> package and not the one from the cmake package even if i list the cmake
> modules directory first with the -DCMAKE_MODULE_PATH argument. I'm not a
> cmake guru so i might be doing something wrong. I put a FATAL_WARNING in the
> kde FindFlex.cmake file to get a call stack and i got the following:
>
> CMake Error at /opt/local/share/apps/cmake/modules/FindFLEX.cmake:17
> (message):
>   Using kdelibs flex.cmake
> Call Stack (most recent call first):
>   /opt/local/share/apps/cmake/modules/MacroOptionalFindPackage.cmake:32
> (find_package)
>   extra/kipi-plugins/CMakeLists.txt:169 (MACRO_OPTIONAL_FIND_PACKAGE)
>
> If i move the FindFlex.cmake file provided by kdelibs out of the way, cmake
> runs fine.
>
> I'm not sure how to solve this cleanly at the moment w/o pano being disabled
> on osx since cmake will never use the proper FineFlex.cmake file. it seems
> that the proper solution would be to remove the FindFlex.cmake file form
> kdelibs since it appears to be distributed with cmake anyway. i don't know
> who controls the distribution files of kdelibs.

It looks like find_package looks first for FindFLEX.cmake in
/opt/local/share/apps/cmake/modules/, before
/opt/local/share/cmake-2.8/modules (note that, from the stack trace,
it looks like the kde version is in
/opt/local/share/apps/cmake/modules/, not in
/opt/local/share/cmake/modules).

On my linux, I also have two FindFLEX.cmake files, one from cmake (in
/usr/share/cmake-2.8/modules) and one from kdelibs (in
/usr/share/apps/cmake/modules/), but the right one is detected.

When I print the value of CMAKE_MODULE_PATH (before the calls to the
macro MACRO_OPTIONAL_FIND_PACKAGE), /usr/share/apps/cmake/modules/ is
listed (last position), but /usr/share/cmake-2.8/modules isn't. What
is the value of your CMAKE_MODULE_PATH?

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

[brad]

>
> It looks like find_package looks first for FindFLEX.cmake in
> /opt/local/share/apps/cmake/modules/, before
> /opt/local/share/cmake-2.8/modules (note that, from the stack trace,
> it looks like the kde version is in
> /opt/local/share/apps/cmake/modules/, not in
> /opt/local/share/cmake/modules).
>
( btw, its embarrassing that you know more about my machine than i do :) )

> On my linux, I also have two FindFLEX.cmake files, one from cmake (in
> /usr/share/cmake-2.8/modules) and one from kdelibs (in
> /usr/share/apps/cmake/modules/), but the right one is detected.
>
> When I print the value of CMAKE_MODULE_PATH (before the calls to the
> macro MACRO_OPTIONAL_FIND_PACKAGE), /usr/share/apps/cmake/modules/ is
> listed (last position), but /usr/share/cmake-2.8/modules isn't. What
> is the value of your CMAKE_MODULE_PATH?
>
You ask a good question which made me hunt more for the problem.

After more work on looking at the value of CMAKE_MODULE_PATH, here's what i
found. It turns out that the CMAKE_MODULE_PATH is always prefixed with
/opt/local/share/apps/cmake/modules/, which is the location of the bad
FindFlex.cmake file and kde-installed cmake modules. After much searching, it
appears that this is because of a line in KdepimLibsConfig.cmake (line 45),
which is used in the MACRO_OPTIONAL_FIND_PACKAGE(KdepimLibs). It prepends to
the CMAKE_MODULE_PATH. That line is the following:

  set(CMAKE_MODULE_PATH "${KDEPIMLIBS_DATA_DIR}/cmake/modules" "${CMAKE_MODULE_PATH}" )

thus, CMAKE_MODULE_PATH is always prefixed with kde's installed cmake modules.
If i comment out this line, cmake in the extras/kipi-plugins directory works
fine. Alternatively a better solution appears to be altering
extras/kipi-plugins/CMakeLists.txt by putting the lines:
  MACRO_OPTIONAL_FIND_PACKAGE(FLEX)
  MACRO_OPTIONAL_FIND_PACKAGE(BISON)
Before the line
  MACRO_OPTIONAL_FIND_PACKAGE(KdepimLibs)

As the CMAKE_MODULE_PATH is untainted until cmake tries to find kdepimlibs.
This alteration would supersede my previous suggestion which was to check for
the existence of the FLEX_TARGET macro.

Also bootstrap.macports:57 would need to be modified to
  -DCMAKE_MODULE_PATH="/opt/local/share/cmake-2.8/Modules;/opt/local/share/cmake/modules"
\

Should i create a set of patches or is this description enough?

There are still some problems i am trying to figure out, but at least cmake
will run properly.

Thanks for reading, cheers,
 - brad

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

[Benjamin Girault]

2013/1/16 brad <[hidden email]>:

>> On my linux, I also have two FindFLEX.cmake files, one from cmake (in
>> /usr/share/cmake-2.8/modules) and one from kdelibs (in
>> /usr/share/apps/cmake/modules/), but the right one is detected.
>>
>> When I print the value of CMAKE_MODULE_PATH (before the calls to the
>> macro MACRO_OPTIONAL_FIND_PACKAGE), /usr/share/apps/cmake/modules/ is
>> listed (last position), but /usr/share/cmake-2.8/modules isn't. What
>> is the value of your CMAKE_MODULE_PATH?
>>
> You ask a good question which made me hunt more for the problem.
>
> After more work on looking at the value of CMAKE_MODULE_PATH, here's what i
> found. It turns out that the CMAKE_MODULE_PATH is always prefixed with
> /opt/local/share/apps/cmake/modules/, which is the location of the bad
> FindFlex.cmake file and kde-installed cmake modules. After much searching, it
> appears that this is because of a line in KdepimLibsConfig.cmake (line 45),
> which is used in the MACRO_OPTIONAL_FIND_PACKAGE(KdepimLibs). It prepends to
> the CMAKE_MODULE_PATH. That line is the following:
>
>   set(CMAKE_MODULE_PATH "${KDEPIMLIBS_DATA_DIR}/cmake/modules" "${CMAKE_MODULE_PATH}" )
>
> thus, CMAKE_MODULE_PATH is always prefixed with kde's installed cmake modules.
> If i comment out this line, cmake in the extras/kipi-plugins directory works
> fine. Alternatively a better solution appears to be altering
> extras/kipi-plugins/CMakeLists.txt by putting the lines:
>   MACRO_OPTIONAL_FIND_PACKAGE(FLEX)
>   MACRO_OPTIONAL_FIND_PACKAGE(BISON)
> Before the line
>   MACRO_OPTIONAL_FIND_PACKAGE(KdepimLibs)
>
> As the CMAKE_MODULE_PATH is untainted until cmake tries to find kdepimlibs.
> This alteration would supersede my previous suggestion which was to check for
> the existence of the FLEX_TARGET macro.
>
> Also bootstrap.macports:57 would need to be modified to
>   -DCMAKE_MODULE_PATH="/opt/local/share/cmake-2.8/Modules;/opt/local/share/cmake/modules"
> \
>
> Should i create a set of patches or is this description enough?

I've pushed your changes on the repository. Thanks.

Cheers,

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