On Mon Mar 3 2014 Barak A. Pearlmutter wrote: > The standard autotools way of "baking in" directories and such into > installed files is to do so at build time, using in the case of C/C++ > things like > > ... -DDATADIR=\"$(datadir)\" ...
I see, ... I guess some people thought very carefully about what is generally the best way. > The analogous mechanism here is to rewrite the string, since the > bbdb-site.el file is not compiled so we cann't bake the directory > into bbdb-site.elc. This is what I've done in the latest patch. > > I suppose one could hotwire "make install" to rewrite the string, > but the usual convention is that what gets installed is exactly > what was built, just copied into the right places, and *maybe* at > most debugging info stripped. Your arguments make sense. My reasoning has been different: If currently we have a file bbdb-site.el.in, even its name is as close as possible to the final file bbdb-site.el. Something like MELPA can use a simple rule *.el.in -> *.el to get things going. Unfortunately, your approach with sed needs to be more complicated (unless I overlook something). If bbdb-print-tex-path gets defined via defcustom in bbdb-site.el, elisp does not require that the value of the variable is hard-coded (not even if the file gets compiled). If the value is a lisp expression, this expression gets evaluated at run time. That's why I thought that this lisp expression could check for the presence of a file bbdb-print-tex-path.el which is read and used to generate the value for bbdb-print-tex-path. If you suggested that the file bbdb-print-tex-path.el should already be created at compile time, that would be fine with me, too. > One argument is: it's got to go *somewhere*, so why not in > bbdb-site.el where people would expect it? Principle of least > surprise. If someone reads the actual code of bbdb-site.el, he'd find the lisp expression that gets evaluated. ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk _______________________________________________ bbdb-info@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bbdb-info BBDB Home Page: http://bbdb.sourceforge.net/
