On 02/07/15 20:13, Martin Lucina wrote:
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? :-)