On 16/06/11 00:31, Dan McGee wrote:
Add a BUILDDIR variable (which can be overridden in the environment) to specify an alternative location for building the package. This is useful for people who want to build on a different filesystem for improved performance (e.g. tmpfs).
Signed-off-by: Allan McRae<allan@archlinux.org> --- doc/makepkg.8.txt | 3 +++ doc/makepkg.conf.5.txt | 5 +++++ etc/makepkg.conf.in | 3 +++ scripts/makepkg.sh.in | 18 ++++++++++++++++-- 4 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/doc/makepkg.8.txt b/doc/makepkg.8.txt index e61f7ab..f15226a 100644 --- a/doc/makepkg.8.txt +++ b/doc/makepkg.8.txt @@ -206,6 +206,9 @@ Environment Variables Folder where the downloaded sources will be stored. Overrides the corresponding value defined in linkman:makepkg.conf[5].
+**BUILDDIR=**"/path/to/folder":: + Folder where the package will be built. Overrides the corresponding + value defined in linkman:makepkg.conf[5].
Configuration ------------- diff --git a/doc/makepkg.conf.5.txt b/doc/makepkg.conf.5.txt index fcd2f2a..4db8b92 100644 --- a/doc/makepkg.conf.5.txt +++ b/doc/makepkg.conf.5.txt @@ -110,6 +110,11 @@ Options running in the DistCC cluster. In addition, you will want to modify your `MAKEFLAGS`.
+**BUILDDIR=**"/path/to/folder":: + If this value is not set, packages will by default be built in the + subdirectories of the current directory. This option allows setting "current directory" seems half right (looks like we use "build
On Wed, Jun 15, 2011 at 4:13 AM, Allan McRae<allan@archlinux.org> wrote: directory" below?), but it appears we only get this whole bit halfway right anyway:
dmcgee@galway ~/projects/arch-repos/libfetch $ makepkg -f -p trunk/PKGBUILD ==> Making package: libfetch 2.33-3 (Wed Jun 15 09:26:08 CDT 2011) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving Sources... ==> ERROR: Makefile was not found in the build directory and is not a URL.
That is a different issue. The -p options has always been a bit weird with alternative builscripts outside the current path and local source files... I have previously considered restricting this to files in the current directory but have never been sure.
Also wondering if it is worth a word of warning here in the manpage stating something like if the package builds without this option but not with this option, the package build script is broken and makes invalid assumptions?
Yes... This is the first real breakage of $startdir/pkg != $pkgdir (and similar for $srcdir), although only in the case where this option is used. I'm not sure how much that needs documented given we have not equated those values in the man pages for a couple of releases now so something like this could happen. Although...
for i in core extra community; do \ grep -R "\$startdir" /var/abs/$i | cut -f1 -d":" | sort | uniq | wc -l \ done 2 48 221
So not everyone listens...