No subject

Mon Sep 28 12:00:37 PDT 2015

# variables to facilitate setting up dependencies to KF5 frameworks tha=
t may (or not)
# also exist as port:kf5-foo-devel .
# This may be extended to provide path-style *runtime* dependencies on =
framework executables;
# kf5.framework_runtime_dependency{name {executable 0}} and kf5.depends=
# (which would have to add a library dependency if no executable depend=
ency is defined).
proc kf5.framework_dependency {name {library 0}} {
    upvar #0 kf5.${name}_dep dep
    upvar #0 kf5.${name}_lib lib
    if {${library} ne 0} {
        global os.platform os.arch
        if {${os.platform} eq "darwin"} {
            set kf5.lib_path    lib
            set kf5.lib_ext     5.dylib
        } elseif {${os.platform} eq "linux"} {
            set kf5.lib_path    lib/${os.arch}-linux-gnu
            set kf5.lib_ext     so.5
        set lib                 ${kf5.lib_path}/${library}.${kf5.lib_ex=
        set dep                 path:${lib}:kf5-${name}
        ui_debug "Dependency expression for KF5ramework ${name}: ${dep}=
    } else {
        if {[info exists dep]} {
            return ${dep}
        } else {
            set allknown [info global "kf5.*_dep"]
            ui_error "No KF5 framework is known corresponding to \"${na=
            ui_msg "Known framework ports: ${allknown}"
            return -code error "Unknown KF5 framework ${name}"

# kf5.depends_frameworks appends the ports corresponding to the KF5 Fra=
# short names to depends_lib
# This procedure also adds the build dependencies that KI18n imposes
# Caution though: some KF5 packages will let the KI18n dependency be ad=
# through cmake's public link interface handling, rather than declaring=
# explicit dependency themselves that is listed in the printed summary.=

proc kf5.depends_frameworks {first args} {
    # join ${first} and (the optional) ${args}
    set args [linsert $args[set list {}] 0 ${first}]
    foreach f ${args} {
        depends_lib-append \
                        [kf5.framework_dependency ${f}]
    if {[lsearch -exact ${args} "ki18n"] ne "-1"} {


kf5.framework_dependency    attica libKF5Attica
kf5.framework_dependency    karchive libKF5Archive
kf5.framework_dependency    kcoreaddons libKF5CoreAddons

Those define variables that make it easier for dependents to depend on =
specific frameworks; with an additional procedure (source not shown) th=
ey can say things like=20

    kf5.depends_build_frameworks \
                    attica karchive kcodecs kconfig \
                    kcoreaddons kdbusaddons kdnssd kguiaddons \
                    ki18n kidletime kimageformats kitemmodels \
                    kitemviews kplotting kwidgetsaddons kwindowsystem \=

                    solid sonnet threadweaver

the best I can currently do to get the list of KF5 dependency portnames=
, is `port deps kf5-tier1-frameworks` and then copy-paste

kf5-kapidox, kf5-attica, kf5-karchive, kf5-kcodecs, kf5-kconfig, kf5-kc=
                      kf5-kdbusaddons, kf5-kdnssd, kf5-kguiaddons, kf5-=
ki18n, kf5-kidletime, kf5-kimageformats, kf5-kitemmodels,
                      kf5-kitemviews, kf5-kplotting, kf5-kwidgetsaddons=
, kf5-kwindowsystem, kf5-solid, kf5-sonnet, kf5-threadweaver

with manual post-processing. It would be easy to add a few lines to kf5=
.depends_build_frameworks that create the list as I want it in a variab=

Similarly, after each update I need to check whether my patching actual=
ly gave the desired result of adding a link-time module to a key librar=
y per subport, the same that is also used for the dependency declaratio=
n. I have a script for that, but it needs to be told what library to ch=
eck. That information is already stored in a variable, but I cannot acc=
ess that information "from outside". So I have a section in the post-de=
stroot, overkill as it only needs to be done once:

post-destroot {
    if {[variant_isset qspXDG]} {
        ui_msg "--->  Checking ${subport} for the QspXDG activator ..."=

        if {[info exists kf5.framework]} {
            upvar #0 kf5.${kf5.framework}_lib lib
        } elseif {[info exists kf5.portingAid]} {
            upvar #0 kf5.${kf5.portingAid}_lib lib
        } else {
            upvar #0 kf5.${kf5.project}_lib lib
        if {[info exists lib]} {
            set libopt "-qsplib ${lib}"
        } else {
            set libopt ""
        if {[catch {system "${filespath}/../ ${libopt} $=
{subport} 2>&1"} result context]} {
            ui_msg "QspXDG activator check failed: ${result}, ${context=
        } else {
            ui_debug "QspXDG activator check: ${result}"

that bit of Tcl could go into a script that only the port maintainer ne=
eds to use when applying an upstream update ...


More information about the macports-dev mailing list