Holy long thread batman! I'll chip in a little but looks like this one has already run most of its course.
On Mon, May 19, 2008 at 6:14 AM, Xavier <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 12:43 PM, Loui <[EMAIL PROTECTED]> wrote: >> On Mon, 19 May 2008 06:25:36 +0200 >> Geoffroy Carrier <[EMAIL PROTECTED]> wrote: >> >>> Excerpts from louipc.ist's message of Mon May 19 07:39:45 +0200 2008: >>> > It would be nice if all three were referenced. I wouldn't feel right if >>> > $startdir disappeared. >>> In the .proto files? >>> >> >> Yeah. A prime place to demonstrate all the variables, non? The *prime* place should be the manpage, not the proto file. Obviously the proto file should provide a reasonable template, but no need to clutter it with unnecessary use of $startdir if $srcdir/$pkgdir can cover it all. So on that note, we should ensure we have startdir, srcdir, and pkgdir all documented in PKGBUILD.5. Looks like currently we have none of these documented. > > I actually also see several advantages for not using $startdir : > 1) pkgdir and srcdir could be independent > 2) shorter and nicer > 3) prevents you from accessing files directly from $startdir : > All files in use need to be put in source array, and these files are > copied from $startdir to $srcdir. > So $srcdir has everything you need. If you use $startdir however, you > can forget to put a file in source array, and you won't notice it > (that is why namcap prints a warning for that, but you need to use > namcap :)) > > and I personally would find it clearer to either use only > $pkgdir/$srcdir or only $startdir. I'm with Xavier here. I think we have reached the point where we can transition to 90% of our usage to being $srcdir/$pkgdir with $startdir only being used in some very specialized cases. As srcdir/pkgdir were introduced with 3.1, 3.2 can safely provide default PKGBUILDs using these variables. -Dan _______________________________________________ pacman-dev mailing list [email protected] http://archlinux.org/mailman/listinfo/pacman-dev
