On Tue, Jun 21, 2011 at 3:31 AM, Allan McRae <[email protected]> wrote: > On 20/06/11 15:38, Dan McGee wrote: >> >> On Thu, Jun 16, 2011 at 5:12 AM, Allan McRae<[email protected]> wrote: >>> >>> On 16/06/11 00:31, Dan McGee wrote: >>>> >>>> On Wed, Jun 15, 2011 at 4:13 AM, Allan McRae<[email protected]> >>>> 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<[email protected]> >>>>> --- >>>>> 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 >>>> 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. >> >> Yeah, sorry- I didn't mean to imply it was the same issue, only >> pointing out the ambiguity of current vs. build directory. >> >>>> 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... >> >> Exactly what I was worried about, wow. >> > > > Improved wording: > > **BUILDDIR=**"/path/to/folder":: > If this value is not set, packages will by default be built in > subdirectories of the directory that makepkg is called from. This > option allows setting the build location to another folder. > Incorrect use of `$startdir` in a PKGBUILD may cause building with > this option to fail.
+1 from me. -Dan
