[MacPorts] #52713: splitting up ports in "runtime" and "-dev" ports, DebUntu style (PoC)
MacPorts
noreply at macports.org
Wed Oct 26 18:47:41 CEST 2016
#52713: splitting up ports in "runtime" and "-dev" ports, DebUntu style (PoC)
-------------------------+--------------------------------
Reporter: RJVB | Owner: macports-tickets@…
Type: enhancement | Status: new
Priority: Normal | Milestone:
Component: base | Version: 2.3.4
Keywords: | Port:
-------------------------+--------------------------------
Hi,
We've talked about this before, the idea used by Debian and Ubuntu (and
other Linux distros) to ship library packages split up in runtime and
"development" packages, where the latter provide the header files and
linker interface (and static) libraries.
I've never had a real reason to pursue that thought, but the other day I
ran into an issue where I needed to keep a port (libvpx) installed but
couldn't in order to build a new port. In a first blunt approach I
confirmed that that situation could be resolved by removing the vpx
headers and link libraries, so since libvpx is outdated anyway I decided
to see how nicely one could implement a -dev port that unpacks a tarball
created by the main/runtime port.
This is what I came up with, as a proof of concept, in hope it may be
useful some day.
{{{
# it shouldn't be necessary to record variants in the archive name
set archname ${name}@${version}-dev.tar.bz2
# this could go into the software images directory and be excluded from
the main port's software image
set archdir ${prefix}/var/devcontent
# Call create_devport_content foo1 foo2 [...fooN] to archive and delete
foo1...fooN
proc create_devport_content {first {args 0}} {
global destroot prefix archname archdir
# join ${first} and (the optional) ${args}
set rawargs [linsert $args[set list {}] 0 ${first}]
set args ""
# convert the arguments to local-relative:
foreach a ${rawargs} {
set args "${args} ./${a}"
}
xinstall -m 755 -d ${destroot}${archdir}
# create the -dev tarball
if {[catch {system -W ${destroot} "bsdtar -cjvf
${destroot}${archdir}/${archname} ${args}"} err]} {
ui_error "Failure creating ${destroot}${archdir}/${archname} for
${args}: ${err}"
file delete -force ${destroot}${archdir}/${archname}
} else {
# success, now remove what we just archived.
# alternatively we could use an archiver capable of deleting
elements on the fly.
foreach a ${args} {
file delete -force ${destroot}/${a}
}
}
}
# unpack_devport_content is called automatically in the -dev port's
destroot phase
# and unpacks the archived development files in that port's destroot.
proc unpack_devport_content {} {
global destroot prefix archname archdir
if {[file exists ${archdir}/${archname}]} {
if {[catch {system -W ${destroot} "bsdtar -xvf
${archdir}/${archname}"} err]} {
ui_error "Failure unpacking ${archdir}/${archname}: ${err}"
}
} else {
ui_error "The port's content doesn't exists
(${archdir}/${archname})!"
return -code error "Missing content"
}
}
# call create_devport with a dependency declaration to create the -dev
subport
# and let it depend on the main/runtime port(s) in the appropriate
fashion.
proc create_devport {dependency} {
global name long_description
subport ${name}-dev {
description "Development headers and libraries for ${name}"
depends_lib-append \
${dependency}
long_description ${long_description}\nThis installs the
development headers and libraries.
installs_libs yes
supported_archs noarch
distfiles
fetch {}
checksum {}
extract {}
use_configure no
patchfiles
build {}
destroot {
unpack_devport_content
}
}
}
}}}
These procedures can now be used as follows:
{{{
create_devport port:${name}
post-destroot {
# it would probably be possible to move the subport/name check into
create_devport_content itself.
if {${subport} eq "${name}"} {
create_devport_content ${prefix}/include/vpx
${prefix}/lib/libvpx.a ${prefix}/lib/libvpx.dylib
}
}
}}}
This wasn't very difficult. It bothers me a bit that the archived
development content is archived itself in the software image, but I don't
see a way around that without hacking into "base".
--
Ticket URL: <https://trac.macports.org/ticket/52713>
MacPorts <https://www.macports.org/>
Ports system for OS X
More information about the macports-tickets
mailing list