#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