From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ian Hulin Newsgroups: gmane.lisp.guile.user,gmane.comp.gnu.lilypond.devel Subject: Re: Generating compiled scm (.go) files as part of LilyPond build Date: Wed, 20 Jul 2011 00:08:18 +0100 Message-ID: <4E260E62.40009@hulin.org.uk> References: <4CF14302.1020502@hulin.org.uk> <4CF6BC51.3090909@hulin.org.uk> <4D1C7061.1000701@hulin.org.uk> <4D433723.50501@hulin.org.uk> <4E25843A.2000803@hulin.org.uk> <8762myjqee.fsf@pobox.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1311116931 25880 80.91.229.12 (19 Jul 2011 23:08:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 19 Jul 2011 23:08:51 +0000 (UTC) Cc: guile-user@gnu.org, "lilypond-devel@gnu.org" To: Andy Wingo Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Jul 20 01:08:46 2011 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QjJP9-0005zs-Uu for guile-user@m.gmane.org; Wed, 20 Jul 2011 01:08:44 +0200 Original-Received: from localhost ([::1]:44550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjJP8-0004md-17 for guile-user@m.gmane.org; Tue, 19 Jul 2011 19:08:42 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjJOs-0004mW-6k for guile-user@gnu.org; Tue, 19 Jul 2011 19:08:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QjJOn-0002NU-Nk for guile-user@gnu.org; Tue, 19 Jul 2011 19:08:26 -0400 Original-Received: from asmtp5.iomartmail.com ([62.128.201.176]:39934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QjJOn-0002N8-B3; Tue, 19 Jul 2011 19:08:21 -0400 Original-Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6JN8JqC031157; Wed, 20 Jul 2011 00:08:19 +0100 Original-Received: from [192.168.1.100] (cpc3-rdng6-0-0-cust547.15-3.cable.virginmedia.com [82.10.50.36]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id p6JN8IxH031151; Wed, 20 Jul 2011 00:08:18 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110624 Thunderbird/5.0 In-Reply-To: <8762myjqee.fsf@pobox.com> X-Enigmail-Version: 1.2 X-MIME-Autoconverted: from 8bit to quoted-printable by asmtp5.iomartmail.com id p6JN8JqC031157 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 62.128.201.176 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:8686 gmane.comp.gnu.lilypond.devel:38020 Archived-At: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue 19 Jul 2011 15:28:41 BST, Andy Wingo wrote: > Hi Ian, >=20 > On Tue 19 Jul 2011 15:18, Ian Hulin writes: >=20 >> It may boil down to a matter of taste, but I find double and >> triple extensions on a filename intrinsically nasty. I've normally >> come across them before on Windows systems where a filename such as >> thing.htm.exe usually means there's malware or a trojan or suchlike >> on your system. See also comments below. >=20 > Consider it an opaque key into a cache. We could change in the > future to default to the SHA1 of the whole path. That does have > some advantages regarding flattening the directory hierarchy, > resulting in fewer stat operations. >=20 Sorry, but how does this benefit LilyPond as a user of the Guile API? I'm used to viewing file extensions as an indication of the format of the file content. In our simple view scheme sources are *.scm, and compiled scheme files are *.go. Guile documentation implies something similar (Chap 4 Environment Variable sections on GUILE_AUTO_COMPILE and GUILE_LOAD_COMPILED_PATH) "If a compiled (=E2=80=98.go=E2=80=99) file corresponding to a =E2=80=98.= scm=E2=80=99 file is not found or is not newer than the =E2=80=98.scm=E2=80=99 file, the =E2=80=98.scm=E2= =80=99 file will be compiled on the fly, and the resulting =E2=80=98.go=E2=80=99 file stored away. An advisory note will b= e printed on the console." "GUILE_LOAD_COMPILED_PATH This variable may be used to augment the path that is searched for compiled Scheme files (=E2=80=98.go=E2=80=99 files) when loading" Neither of these sections leads the reader to expect an actual file name generated to be ;;; compiled /long/path/name/testing.scm.go ^^^^^^^ >> ian@nanny-ogg:~/src/Guile/guile-2.0.2$ meta/guile -L $PWD >=20 > This will set XDG_CACHE_HOME=3D${top_builddir}/cache. >=20 The Guile Reference Manual Chapter 4 p 38 specifically says this defaults to $HOME/cache >> The problem is knowing where the cache is. For Lilypond, we need to >> have a common root directory off of which we can hang the compiled >> files in scm/out. >=20 > Why do you care? (Honest question.) >=20 (Honest answer) Because if Lilypond is run up with the Guile default of --auto-compile it will check for and generate compiled files in a different place to where we want to have produced them at build-time. Also once for a project like LilyPond these files would need to be in a shared directory on the file system. Relying on the default compiled file spec would have a set of cached files somewhere on each user's cache in their home directory. > To me there are two cases: >=20 > 1) You compile the files yourself. You either ensure that the .go=20 > files end up in the right places, or adjust=20 > GUILE_LOAD_COMPILED_PATH. >=20 But GUILE_LOAD_COMPILED_PATH setting won't prevent the vanilla compiled-file-name from checking in the wrong place for at compile time. OK we can brew our own expectation of where the file will be, and provide our own ly:load and intelligence to pick up the compiled file, but we have to do this in conjunction with a scm_putenv("GUILE_AUTO_COMPILE=3D0") call in our initialization code. > 2) You rely on autocompilation. In this case there is no guarantee=20 > about where the files go, besides residing in the=20 > XDG_CACHE_DIR/guile. >=20 Looks like this is a no-no. We can't control what the files are called, or if they'd be recognized once they've been moved to their location after /make install/ for LilyPond. Also there's the issue of embedded Scheme statements in Lily source files (which could contain their own (load "xxxx") statements). It's a real shame because it looks like auto-compile is a feature designed to make life easy for Guile users (including layered projects like LilyPond). Unfortunately its default settings prevent us from using it. :-(. I've also got a question re the (include) procedure which Ludovic mentioned in a post on guile-users. I'll start a different thread for that one. Thanks for the help so far, Cheers, Ian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOJg5cAAoJEBqidDirZqASMj0H/2jn/jiNG+MtT+YEc762baxL 8pMC4ijNMwWEnMwzuWm1LHhHiJqG5roxvinPoe5bjeC8RBNSMOW7SKGkJ+ao5pTK vYfBm55WqdpAvAVQA9OaDkL6J33TEa6z1ioNYxj2yFOHHsj0HHVnhUM29RDNYgmw 9duK9lKtv37AGT0W9aj6bGx8FRGFUOFgRUnHMCtn7usE1DboXQgjaY3IQ46XYs6n XGfuFz1JBXqhKEjjK7Fbu5M44A0eD2yWGJ01K3eVQqB1OmIrz7zy7wU495Wqd4im /eop+BCJRnpRAdHIR0y/LgrrlPSpD+mulBk9BOuoAglXM6N8spaQQY/mj8MkrKU=3D =3DigTg -----END PGP SIGNATURE-----