On Tuesday December 15 2015 10:17:58 Daniel J. Luke wrote:

> Anything is possible, although this seems like a bad idea to me.

I agree it could lead to lots of problems when wielded in the wrong hands (so 
it might be better to use a dedicated utility rather than the port command 
itself).

> Maybe if you included a concise description of exactly what you're trying to 
> do, someone would have an alternate idea that would work?

>From my KF5 PortGroup:

{{{
# variables to facilitate setting up dependencies to KF5 frameworks that 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_run_frameworks
# (which would have to add a library dependency if no executable dependency 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_ext}
        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 \"${name}\""
            ui_msg "Known framework ports: ${allknown}"
            return -code error "Unknown KF5 framework ${name}"
        }
    }
}

# kf5.depends_frameworks appends the ports corresponding to the KF5 Frameworks
# 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 added
# through cmake's public link interface handling, rather than declaring an
# 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.has_translations
    }
}

#snip

kf5.framework_dependency    attica libKF5Attica
kf5.framework_dependency    karchive libKF5Archive
kf5.framework_dependency    kcoreaddons libKF5CoreAddons
#etc
}}}

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

{{{
    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-kcoreaddons,
                      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 variable.

Similarly, after each update I need to check whether my patching actually gave 
the desired result of adding a link-time module to a key library per subport, 
the same that is also used for the dependency declaration. I have a script for 
that, but it needs to be told what library to check. That information is 
already stored in a variable, but I cannot access that information "from 
outside". So I have a section in the post-destroot, 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}/../check-qspxdg.sh ${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 needs to 
use when applying an upstream update ...

Cheers,
René

_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to