[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