Opened 8 years ago

Last modified 3 years ago

#52713 new enhancement

splitting up ports in "runtime" and "-dev" ports, DebUntu style (PoC)

Reported by: RJVB (René Bertin) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 2.3.4
Keywords: Cc: mascguy (Christopher Nielsen)
Port:

Description

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".

Attachments (1)

devport-1.0.tcl (5.3 KB) - added by RJVB (René Bertin) 8 years ago.

Download all attachments as: .zip

Change History (2)

Changed 8 years ago by RJVB (René Bertin)

Attachment: devport-1.0.tcl added

comment:1 Changed 3 years ago by mascguy (Christopher Nielsen)

Cc: mascguy added
Note: See TracTickets for help on using tickets.