invitation: try compiling kdelibs using cmake

[Benjamin Reed]

On 1/27/06, Brad King <brad.king at kitware.com> wrote:

> You can get the per-target part of that right now:
>
> SET_TARGET_PROPERTIES(mylib PROPERTIES LINK_FLAGS -no-undefined)
>
> As far as per-os you'll still have to test the platform before adding
> the flag with the above command.  We've talked about having a mapping of
> generic feature names (warning level, optimization level, etc.) to
> specific flags on each platform but it has not yet been implemented.

right, but "-no-undefined" is a feature of libtool, and gets
translated into different things depending on the host.  (on OSX,
there are no -flat_namespace -undefined suppress -undefined
dynamic_lookup, etc. when using -no-undefined, on linux it passes
-Wl,--no-undefined to gnu ld, etc.)

for example, GNU libtool on darwin does this to determine how to allow
undefined symbols:

---(snip!)---
       *) # Darwin 1.3 on
         if test -z ${MACOSX_DEPLOYMENT_TARGET} ; then
           _LT_AC_TAGVAR(allow_undefined_flag,
$1)='${wl}-flat_namespace ${wl}-undefined ${wl}suppress'
         else
           case ${MACOSX_DEPLOYMENT_TARGET} in
             10.[[012]])
               _LT_AC_TAGVAR(allow_undefined_flag,
$1)='${wl}-flat_namespace ${wl}-undefined ${wl}suppress'
               ;;
             10.*)
               _LT_AC_TAGVAR(allow_undefined_flag,
$1)='${wl}-undefined ${wl}dynamic_lookup'
               ;;
           esac
         fi
         ;;
---(snip!)---

Depending on the deployment target, it picks the "best" option for
getting good symbol resolution.  That's why it's more suitable to be a
cmake general feature, IMHO.  This is crazy logic to be implementing
per-project.

But for now it's a minor thing, I'll just say "allow undefined symbols
always" and we can tighten up the restrictions later.  :)