On Thursday, 02.07.2015 at 13:05, Antti Kantee wrote:
> On 01/07/15 20:16, Antti Kantee wrote:
> >>It'd be good if the other packages in rumprun-packages-wip could make use
> >>of this infrastructure to build rather than having a list of manual
> >>steps.
> >
> >Good idea. I'll convert mpg123. I secretly hope that Krishna will
> >convert python as part of his "python-static" work ;)
>
> Ok, did that, 'twas simple enough.
Good.
> I guess we could also do with a Makefile.inc, a lot of make targets
> seem the same for every package. Not that I want this stopgap
> packaging system to turn into a reimplementation of pkgsrc, but
> anyway ;)
I agree, however I'm not too hung up on using make. The common boilerplate
consists of mostly a sequential set of "fetch upstream", "maybe patch",
"maybe configure", "build", "install", "maybe make images" steps.
I was thinking that we could build a small DSL for packaging using shell
scripts. Imagine a build.sh that looked something like this:
#!/bin/sh
. ../scripts/common.sh
package nginx
upstream http://nginx.org/download/nginx-1.8.0.tar.gz
patches patches/*
NGINX_CONF_ENV=...
NGINX_CONF_OPTS=...
configure ./configure ${NGINX_CONF_OPTS}
build make
install objs/nginx nginx.bin
iso_image stubetc.iso ../stubetc/etc
iso_image data.iso images/data
This should be pretty trivial to write, probably a couple of hours work.
Observant readers will note that the "syntax" is somewhat inspired by OPAM.
Thoughts?
> I used the following to deduce the --host value to ./configure:
> HOST=$(subst -cc,,$(notdir $(CC)))
>
> I wonder, with the toolchain rename, is that always correct for us?
Yes. However I'm wondering if we want a bit more "infrastructure" that
makes it clear what target and/or bake configuration the user is building
packages for, and just does the whole lot. Or perhaps this is getting too
much like a packaging system? :-)
