From owner-freebsd-ports Fri Mar 29 15:48:23 2002 Delivered-To: freebsd-ports@freebsd.org Received: from wopr.caltech.edu (wopr.caltech.edu [131.215.103.10]) by hub.freebsd.org (Postfix) with ESMTP id 3E9EA37B417 for ; Fri, 29 Mar 2002 15:48:18 -0800 (PST) Received: (from mph@localhost) by wopr.caltech.edu (8.11.6/8.9.3) id g2TNmHs80164 for ports@freebsd.org; Fri, 29 Mar 2002 15:48:17 -0800 (PST) (envelope-from mph) Date: Fri, 29 Mar 2002 15:48:17 -0800 From: Matthew Hunt To: ports@freebsd.org Subject: Bento errorlogs and /dev/fd/* Message-ID: <20020329154817.A79447@wopr.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I maintain the games/crafty-open-rock port. This port fetches an archive of a bunch of chess games, and runs the chess program "crafty" in a mode which analyses all of the games and builds an opening book. The distfiles are a sequence of 10 files, which can be cat(1)ed together to produce a .zip file. This .zip file contains only one member file, and hence gzip(1) can extract it. The compressed files total 116 MB. The uncompressed contents would occupy another 375 MB. However, in order to prevent the people building the port from needing to have that much space free, I have employed a trick. The "crafty" program only needs to read the file sequentially (e.g. one line at a time). I therefore use "gzip -dc" to provide the uncompressed data on file descriptor 3, and tell crafty to use /dev/fd/3 as the filename of the game data: # (cd ${DISTDIR}/${DIST_SUBDIR} && ${CAT} ${DISTFILES} | ${GUNZIP_CMD}) | (cd ${WRKDIR}; crafty 3<&0 < ${FILESDIR}/book-building) where ${FILESDIR}/book-building includes the "crafty" command: # book create /dev/fd/3 60 3 However, it appears from the errorlog, , that /dev/fd/3 is not available in the package build environment. I am open to suggestions as to what to do, including: - Stop being clever, and make everyone uncompress the 375 MB. This will annoy me: Filesystem Size Used Avail Capacity Mounted on /dev/da0s1e 1.9G 1.7G 43M 98% /usr Also, there would be the time required to actually write all of those bytes to disk. - If PACKAGE_BUILDING is set, uncompress the file instead of using the /dev/fd/3 trick. - If /dev/fd/3 exists, use it, otherwise uncompress the file - See if /dev/fd/* can be provided in the package-building environment - Not provide a package for this port (but it takes a long time to "build" and the package is probably a useful service; the resulting opening book is also much smaller than the game data that goes into it). So, opinions? Thanks, Matt -- Matthew Hunt * Science rules. http://www.pobox.com/~mph/ * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message