[kdelibs/KDE/4.7] cmake/modules: fixed cmake trying to link against the dll directly
Alexander Neundorf
neundorf at kde.org
Mon Oct 31 20:12:10 UTC 2011
On Sunday 30 October 2011, Patrick von Reth wrote:
> Git commit cf65947f74acbdfbe948cf768266c308baa17f96 by Patrick von Reth.
> Committed on 30/10/2011 at 17:24.
> Pushed by vonreth into branch 'KDE/4.7'.
>
> fixed cmake trying to link against the dll directly
>
> M +4 -0 cmake/modules/FindHUpnp.cmake
>
> http://commits.kde.org/kdelibs/cf65947f74acbdfbe948cf768266c308baa17f96
>
> diff --git a/cmake/modules/FindHUpnp.cmake b/cmake/modules/FindHUpnp.cmake
> index 0f4207e..98b10d8 100644
> --- a/cmake/modules/FindHUpnp.cmake
> +++ b/cmake/modules/FindHUpnp.cmake
> @@ -13,6 +13,10 @@
>
> find_path( HUPNP_INCLUDE_DIR HUpnpCore/HUpnp )
>
> +if( WIN32 )
> + #I don't know why its needed but without it cmake tries to link
> against the dll directly + set(CMAKE_FIND_LIBRARY_SUFFIXES
> ".dll.a;.a;.lib;")
> +endif( WIN32 )
> find_library( HUPNP_LIBS NAMES HUpnp HUpnp1 )
>
> if( HUPNP_INCLUDE_DIR AND EXISTS
> "${HUPNP_INCLUDE_DIR}/HUpnpCore/public/hupnpinfo.h" )
Now this looks really wrong.
Can you explain why that is needed ?
If not, please revert it.
You are setting a cmake-internal variable in a Find-file, even without
resetting it.
This is completely unexpected behaviour for a Find-module and may cause any
kind of breakage later on.
Alex
More information about the Kde-buildsystem
mailing list