* BBDB v3 approaching release @ 2013-05-27 8:18 Roland Winkler 2013-05-27 8:49 ` Leo Liu [not found] ` <87obbvwgw6.fsf@sbs.ch> 0 siblings, 2 replies; 38+ messages in thread From: Roland Winkler @ 2013-05-27 8:18 UTC (permalink / raw To: emacs-devel BBDB v3 has matured on Savannah for quite some time and I want to get it ready for a proper release. Yet there are two things where I'd appreciate some help: - The current configure scripts and makefiles pretty much follow the old lines of BBDB v2. I'd be glad if someone familiar with the GNU conventions for such files could look over these files so that they work reliably / as expected on different platforms. - What needs to be done to actually release BBDB so that users can download the tar ball from some server? How to arrange for something like a checksum so that users can trust the tar ball? Any other comments are welcome, too. Roland BBDB is available at http://savannah.nongnu.org/projects/bbdb/ To check it out, use git clone git://git.savannah.nongnu.org/bbdb.git ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 8:18 BBDB v3 approaching release Roland Winkler @ 2013-05-27 8:49 ` Leo Liu 2013-05-27 15:13 ` Stefan Monnier [not found] ` <87obbvwgw6.fsf@sbs.ch> 1 sibling, 1 reply; 38+ messages in thread From: Leo Liu @ 2013-05-27 8:49 UTC (permalink / raw To: emacs-devel On 2013-05-27 16:18 +0800, Roland Winkler wrote: > - What needs to be done to actually release BBDB so that users can > download the tar ball from some server? How to arrange for > something like a checksum so that users can trust the tar ball? GNU ELPA is good for distribution. Leo ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 8:49 ` Leo Liu @ 2013-05-27 15:13 ` Stefan Monnier 2013-05-27 16:13 ` Roland Winkler 0 siblings, 1 reply; 38+ messages in thread From: Stefan Monnier @ 2013-05-27 15:13 UTC (permalink / raw To: Leo Liu; +Cc: emacs-devel >> - What needs to be done to actually release BBDB so that users can >> download the tar ball from some server? How to arrange for >> something like a checksum so that users can trust the tar ball? > GNU ELPA is good for distribution. But it's only for code whose copyright was assigned to the FSF. While BBDBv3 has a lot of new code by Roland, AFAICT it still shares a non-trivial amount of code with the old codebase for which we don't have copyright assignments. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 15:13 ` Stefan Monnier @ 2013-05-27 16:13 ` Roland Winkler 2013-05-27 16:57 ` Stefan Monnier 0 siblings, 1 reply; 38+ messages in thread From: Roland Winkler @ 2013-05-27 16:13 UTC (permalink / raw To: emacs-devel On Mon, May 27 2013, Stefan Monnier wrote: >> GNU ELPA is good for distribution. > > But it's only for code whose copyright was assigned to the FSF. > While BBDBv3 has a lot of new code by Roland, AFAICT it still shares > a non-trivial amount of code with the old codebase for which we don't > have copyright assignments. Identifying the old pieces of code in BBDB v3, which do require copyright assignments, is also on my to-do list. Maybe the amount of old code is really not significant anymore. I cannot tell myself and it is a somewhat tedious excercise to check this properly. (Help welcome!) Yet I think that in the meanwhile, it would be nice to have a proper release of BBDB v3. Roland ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 16:13 ` Roland Winkler @ 2013-05-27 16:57 ` Stefan Monnier 2013-05-27 19:28 ` Roland Winkler 0 siblings, 1 reply; 38+ messages in thread From: Stefan Monnier @ 2013-05-27 16:57 UTC (permalink / raw To: Roland Winkler; +Cc: emacs-devel > Yet I think that in the meanwhile, it would be nice to have a proper > release of BBDB v3. Definitely. You can package it in the format used for ELPA packages (you don't even need a Makefile for that). Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 16:57 ` Stefan Monnier @ 2013-05-27 19:28 ` Roland Winkler 2013-05-27 19:35 ` Dmitry Gutov 2013-05-27 20:59 ` Stefan Monnier 0 siblings, 2 replies; 38+ messages in thread From: Roland Winkler @ 2013-05-27 19:28 UTC (permalink / raw To: Stefan Monnier; +Cc: emacs-devel On Mon May 27 2013 Stefan Monnier wrote: > You can package it in the format used for ELPA packages (you don't even > need a Makefile for that). From a more practical perspective, what would be suitbable routes to distribute "it", if ELPA is currently not available for BBDB? ("it" = a tar ball?) ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 19:28 ` Roland Winkler @ 2013-05-27 19:35 ` Dmitry Gutov 2013-05-27 20:18 ` Roland Winkler 2013-05-27 20:59 ` Stefan Monnier 1 sibling, 1 reply; 38+ messages in thread From: Dmitry Gutov @ 2013-05-27 19:35 UTC (permalink / raw To: Roland Winkler; +Cc: Stefan Monnier, emacs-devel "Roland Winkler" <winkler@gnu.org> writes: > On Mon May 27 2013 Stefan Monnier wrote: >> You can package it in the format used for ELPA packages (you don't even >> need a Makefile for that). > > From a more practical perspective, what would be suitbable routes > to distribute "it", if ELPA is currently not available for BBDB? > ("it" = a tar ball?) http://marmalade-repo.org/ and/or http://melpa.milkbox.net/. The latter doesn't use tarballs, you just create a recipe and point it to your repository. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 19:35 ` Dmitry Gutov @ 2013-05-27 20:18 ` Roland Winkler 2013-05-28 5:32 ` Ulrich Mueller 0 siblings, 1 reply; 38+ messages in thread From: Roland Winkler @ 2013-05-27 20:18 UTC (permalink / raw To: Dmitry Gutov; +Cc: emacs-devel On Mon May 27 2013 Dmitry Gutov wrote: > http://marmalade-repo.org/ and/or http://melpa.milkbox.net/. > > The latter doesn't use tarballs, you just create a recipe and > point it to your repository. Maybe I am old-fashioned here: I had been thinking about releasing a tar ball that comes with a configure script and makefiles to compile and install BBDB. One reason for this is that BBDB includes tex files required for printing BBDB. These files usually reside in some tex directory outside the usual emacs tree. (What happens to other packages hosted on savannah? How are they released? Maybe this is also something I should look for on the savannah mailing list.) Or is all this really outdated?? Roland ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 20:18 ` Roland Winkler @ 2013-05-28 5:32 ` Ulrich Mueller 2013-05-28 7:49 ` Roland Winkler 2013-05-28 12:34 ` Stefan Monnier 0 siblings, 2 replies; 38+ messages in thread From: Ulrich Mueller @ 2013-05-28 5:32 UTC (permalink / raw To: Roland Winkler; +Cc: emacs-devel, Dmitry Gutov >>>>> On Mon, 27 May 2013, Roland Winkler wrote: > Maybe I am old-fashioned here: I had been thinking about releasing a > tar ball that comes with a configure script and makefiles to compile > and install BBDB. Please do. Packages without a build system impose additional work upon all distros. > One reason for this is that BBDB includes tex files required for > printing BBDB. These files usually reside in some tex directory > outside the usual emacs tree. Ulrich ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-28 5:32 ` Ulrich Mueller @ 2013-05-28 7:49 ` Roland Winkler 2013-05-28 12:34 ` Stefan Monnier 1 sibling, 0 replies; 38+ messages in thread From: Roland Winkler @ 2013-05-28 7:49 UTC (permalink / raw To: Ulrich Mueller; +Cc: emacs-devel On Tue May 28 2013 Ulrich Mueller wrote: > Please do. Packages without a build system impose additional work > upon all distros. ...which brings me back to part one of my original post: The current configure scripts and makefiles pretty much follow the old lines of BBDB v2. I'd be glad if someone familiar with the GNU conventions for such files could look over these files so that they work reliably / as expected on different platforms. Roland ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-28 5:32 ` Ulrich Mueller 2013-05-28 7:49 ` Roland Winkler @ 2013-05-28 12:34 ` Stefan Monnier 1 sibling, 0 replies; 38+ messages in thread From: Stefan Monnier @ 2013-05-28 12:34 UTC (permalink / raw To: Ulrich Mueller; +Cc: Dmitry Gutov, Roland Winkler, emacs-devel >> Maybe I am old-fashioned here: I had been thinking about releasing a >> tar ball that comes with a configure script and makefiles to compile >> and install BBDB. > Please do. Packages without a build system impose additional work upon > all distros. If the package follows the ELPA conventions, then it comes with a build system. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-27 19:28 ` Roland Winkler 2013-05-27 19:35 ` Dmitry Gutov @ 2013-05-27 20:59 ` Stefan Monnier 1 sibling, 0 replies; 38+ messages in thread From: Stefan Monnier @ 2013-05-27 20:59 UTC (permalink / raw To: Roland Winkler; +Cc: emacs-devel >> You can package it in the format used for ELPA packages (you don't even >> need a Makefile for that). > From a more practical perspective, what would be suitbable routes > to distribute "it", if ELPA is currently not available for BBDB? > ("it" = a tar ball?) You can put the tarball anywhere you like. People can then install it via M-x package-install-file, which will byte-compile it, setup autoloads, and put it under ~/.emacs.d/elpa along with any accompanying files, so you should be able to find those .tex auxiliary files at run-time without any difficulty. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
[parent not found: <87obbvwgw6.fsf@sbs.ch>]
* Re: BBDB v3 approaching release [not found] ` <87obbvwgw6.fsf@sbs.ch> @ 2013-05-28 21:23 ` Roland Winkler 2013-05-28 22:29 ` Stefan Monnier 0 siblings, 1 reply; 38+ messages in thread From: Roland Winkler @ 2013-05-28 21:23 UTC (permalink / raw To: Christian Egli; +Cc: emacs-devel On Tue May 28 2013 Christian Egli wrote: > > - The current configure scripts and makefiles pretty much follow the > > old lines of BBDB v2. I'd be glad if someone familiar with the GNU > > conventions for such files could look over these files so that > > they work reliably / as expected on different platforms. > > I know my way around autotools and have some understanding of the GNU > conventions. I looked at configure.ac and Makefile.in. I could help. > What exactly is it that you want to do? Just port the build system to > more modern and standard autotools usage? Hi Christian Thanks! - One concern is about the options of the ./configure script related to the installation of BBDB. Say, currently the options --prefix and --datadir don't do anything meaningful. But I don't know what would be meaningful here. I am really a novice with that stuff. So possibly there are more problems hidden that I have not yet realized. Roland ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-28 21:23 ` Roland Winkler @ 2013-05-28 22:29 ` Stefan Monnier 2013-05-29 13:27 ` Roland Winkler 2013-05-29 16:45 ` Ulrich Mueller 0 siblings, 2 replies; 38+ messages in thread From: Stefan Monnier @ 2013-05-28 22:29 UTC (permalink / raw To: Roland Winkler; +Cc: Christian Egli, emacs-devel > I am really a novice with that stuff. So possibly there are more > problems hidden that I have not yet realized. You *really* want to stick to the ELPA format. It's simple and straightforward for you, and for the end-users. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-28 22:29 ` Stefan Monnier @ 2013-05-29 13:27 ` Roland Winkler 2013-05-29 16:45 ` Ulrich Mueller 1 sibling, 0 replies; 38+ messages in thread From: Roland Winkler @ 2013-05-29 13:27 UTC (permalink / raw To: Stefan Monnier; +Cc: Christian Egli, emacs-devel On Tue May 28 2013 Stefan Monnier wrote: > > I am really a novice with that stuff. So possibly there are more > > problems hidden that I have not yet realized. > > You *really* want to stick to the ELPA format. > It's simple and straightforward for you, and for the end-users. Thanks, I'll look into this. Roland ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-28 22:29 ` Stefan Monnier 2013-05-29 13:27 ` Roland Winkler @ 2013-05-29 16:45 ` Ulrich Mueller 2013-05-29 22:29 ` Stefan Monnier 2013-06-01 14:34 ` Steinar Bang 1 sibling, 2 replies; 38+ messages in thread From: Ulrich Mueller @ 2013-05-29 16:45 UTC (permalink / raw To: Stefan Monnier; +Cc: Christian Egli, Roland Winkler, emacs-devel >>>>> On Tue, 28 May 2013, Stefan Monnier wrote: > You *really* want to stick to the ELPA format. It's simple and > straightforward for you, and for the end-users. How do I configure install locations of a package if it's in ELPA format? Especially, if the package has non-lisp components? Ulrich ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-29 16:45 ` Ulrich Mueller @ 2013-05-29 22:29 ` Stefan Monnier 2013-05-30 7:14 ` Roland Winkler 2013-05-30 9:37 ` Ulrich Mueller 2013-06-01 14:34 ` Steinar Bang 1 sibling, 2 replies; 38+ messages in thread From: Stefan Monnier @ 2013-05-29 22:29 UTC (permalink / raw To: Ulrich Mueller; +Cc: Christian Egli, Roland Winkler, emacs-devel >> You *really* want to stick to the ELPA format. It's simple and >> straightforward for you, and for the end-users. > How do I configure install locations of a package if it's in ELPA > format? You don't. > Especially, if the package has non-lisp components? You leave them alongside the Elisp files. And when you need them, your Elisp package will find them by looking around itself (it can get access to its own location via `load-file-name'). Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-29 22:29 ` Stefan Monnier @ 2013-05-30 7:14 ` Roland Winkler 2013-05-30 7:57 ` Jambunathan K 2013-05-30 8:04 ` Stephen J. Turnbull 2013-05-30 9:37 ` Ulrich Mueller 1 sibling, 2 replies; 38+ messages in thread From: Roland Winkler @ 2013-05-30 7:14 UTC (permalink / raw To: Stefan Monnier; +Cc: Ulrich Mueller, Christian Egli, emacs-devel On Wed May 29 2013 Stefan Monnier wrote: > > How do I configure install locations of a package if it's in ELPA > > format? > > You don't. > > > Especially, if the package has non-lisp components? > > You leave them alongside the Elisp files. And when you need them, your > Elisp package will find them by looking around itself (it can get > access to its own location via `load-file-name'). BBDB contains three TeX files that are required by plain TeX when you want to print the database. Here BBDB creates a TeX file that contains for example \input bbdb-print \input bbdb-cols In a texmf installation, these files would go into a directory like /usr/local/share/texmf/bbdb I do not know where other TeX installations expect to find such files. Can the ELPA format handle such files, too? How? In a way, I am surprised that I do not know about other elisp packages having similar needs. Whenever you want to print something with (La)TeX, you normally need some kind of style file that (La)TeX needs to find. Of course, one work around would be that emacs includes the style file into the TeX files it generates. One advantage of such an approach would be that the resulting TeX files become self-contained for any "standard" TeX installation so that one can forward the TeX files to someone who does not have the BBDB tex files installed. But I consider the forwarding of such files a more rare scenario. Roland ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 7:14 ` Roland Winkler @ 2013-05-30 7:57 ` Jambunathan K 2013-05-30 8:04 ` Stephen J. Turnbull 1 sibling, 0 replies; 38+ messages in thread From: Jambunathan K @ 2013-05-30 7:57 UTC (permalink / raw To: Roland Winkler Cc: Ulrich Mueller, Christian Egli, Stefan Monnier, emacs-devel > Can the ELPA format handle such files, too? How? ELPA is just a tar bundle. You can include whatever you want as part of the bundle. > In a way, I am surprised that I do not know about other elisp > packages having similar needs. Whenever you want to print something > with (La)TeX, you normally need some kind of style file that (La)TeX > needs to find. Org's ODT exporter depends on XML style files for it's export. The style files are included right within the tar ball as part of ./etc/ directory. See http://elpa.gnu.org/packages/org.html. (I think using "./etc" for bundling "data files" is a good precedent.) `load-file-name' is your friend. (defconst org-odt-lib-dir (file-name-directory load-file-name) "Location of ODT exporter. Use this to infer values of `org-odt-styles-dir' and `org-odt-schema-dir'.") (defvar org-odt-data-dir (expand-file-name "./etc/" org-odt-lib-dir) "Data directory for ODT exporter. Use this to infer values of `org-odt-styles-dir' and `org-odt-schema-dir'.") > Of course, one work around would be that emacs includes the style > file into the TeX files it generates. One advantage of such an > approach would be that the resulting TeX files become self-contained > for any "standard" TeX installation so that one can forward the TeX > files to someone who does not have the BBDB tex files installed. > But I consider the forwarding of such files a more rare scenario. Bundle things in a way that minimizes headaches for you and others. In the long run, you can do away with BDBD specific style files and use some packages that (already) come with Tex. Or move the BDBB style files to Tex distribution. 2 cents. > Roland ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 7:14 ` Roland Winkler 2013-05-30 7:57 ` Jambunathan K @ 2013-05-30 8:04 ` Stephen J. Turnbull 2013-05-30 11:16 ` Roland Winkler 1 sibling, 1 reply; 38+ messages in thread From: Stephen J. Turnbull @ 2013-05-30 8:04 UTC (permalink / raw To: Roland Winkler Cc: Ulrich Mueller, Christian Egli, Stefan Monnier, emacs-devel Roland Winkler writes: > In a texmf installation, these files would go into a directory like > /usr/local/share/texmf/bbdb > I do not know where other TeX installations expect to find such files. > > Can the ELPA format handle such files, too? How? TeX is happy to pick up such files from the current directory. Why would it be a problem? If that doesn't work or the BBDB includes are shadowed, TEXINPUTS=.:$TEXINPUTS should do the trick. man kpathsea for more information about telling TeX where to find stuff. But mostly people are going to do such formatting in a proper source tree. Not your problem. The GPL (maybe, but certainly FLOSS courtesy) requires that you provide a "script" (ie, Makefile) to rebuild if people want to modify in-place, but for the info files that can be as simple as bbdb.info: bbdb.texi makeinfo bbdb.texi bbdb.html: bbdb.texi makeinfo --html bbdb.texi bbdb.pdf: bbdb.texi <style files ...> makeinfo --pdf bbdb.texi At least, I should think so. If you normally use @setfilename to put the info etc someplace other than the current directory, use the -o option to put it in the current directory. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 8:04 ` Stephen J. Turnbull @ 2013-05-30 11:16 ` Roland Winkler 2013-05-30 17:25 ` Stephen J. Turnbull 0 siblings, 1 reply; 38+ messages in thread From: Roland Winkler @ 2013-05-30 11:16 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: emacs-devel On Thu May 30 2013 Stephen J. Turnbull wrote: > TeX is happy to pick up such files from the current directory. Why > would it be a problem? If that doesn't work or the BBDB includes are > shadowed, TEXINPUTS=.:$TEXINPUTS should do the trick. man kpathsea > for more information about telling TeX where to find stuff. Normally the user directory where bbdb-print creates its TeX file is not (should not be!) the directory where BBDB keeps its TeX include files. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 11:16 ` Roland Winkler @ 2013-05-30 17:25 ` Stephen J. Turnbull 2013-05-30 17:55 ` Stephen J. Turnbull 0 siblings, 1 reply; 38+ messages in thread From: Stephen J. Turnbull @ 2013-05-30 17:25 UTC (permalink / raw To: Roland Winkler; +Cc: emacs-devel Roland Winkler writes: > On Thu May 30 2013 Stephen J. Turnbull wrote: > > TeX is happy to pick up such files from the current directory. Why > > would it be a problem? If that doesn't work or the BBDB includes are > > shadowed, TEXINPUTS=.:$TEXINPUTS should do the trick. man kpathsea > > for more information about telling TeX where to find stuff. > > Normally the user directory where bbdb-print creates its TeX file is > not (should not be!) the directory where BBDB keeps its TeX include > files. That's one good way to do it, but not necessarily normal. An installed ELPA package can (and IMO should) be thought of as a binary whose internal structure happens to take advantage of the file system to organize its parts rather than ELF sections or zipfile members. In this it's similar to a Python package or a Mac OS X .app. People who want to fiddle with the internals of a package really should do so in the *source* tree, not in the installed tree. The installed tree will have a more convenient layout for source browsing. I'll grant that the info files are a special case and a PITA because they really do like to live in one directory. Nevertheless that can be dealt with in a number of ways (I think XEmacs implements three, none of them particularly attractive). Ulrich mentioned FHS. Well, I haven't read the FHS carefully in a decade, but IIRC from back then, the FHS does not in any way rule out such "opaque packages". If you want your package resources to be available via system facilities (and for man pages and info files you certainly do, thus the exception just mentioned), then indeed you want to follow FHS. But internal resources (including build-time-only resources) can go anywhere you want. There are disadvantages to "opaque packages". It can take a lot more stats to find stuff if you have a very flexible path search algorithm such as kpathsea, which slows things quite a bit. On those occasions you do want to break the veil, what you see inside the package may be neither pretty nor convenient. But by the same token they tend to increase cohesion and decrease coupling, which are usually considered design goals. You don't have to like this approach; I'm just saying it's one way to look at ELPA packages that helps to rationalize them and emphasize their benefits. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 17:25 ` Stephen J. Turnbull @ 2013-05-30 17:55 ` Stephen J. Turnbull 2013-05-30 18:22 ` Eli Zaretskii 0 siblings, 1 reply; 38+ messages in thread From: Stephen J. Turnbull @ 2013-05-30 17:55 UTC (permalink / raw To: Roland Winkler, emacs-devel Stephen J. Turnbull writes: > Roland Winkler writes: > > Normally the user directory where bbdb-print creates its TeX file is > > not (should not be!) the directory where BBDB keeps its TeX include > > files. > > That's one good way to do it, but not necessarily normal. Ah, I didn't know what bbdb-print does. Now that I do, I don't see what's so hard about (shell-command (format "TEXINPUTS=%s%s tex %s" (bbdb-style-file-directory) (getenv "TEXINPUTS") file-to-tex)) where (defcustom bbdb-style-file-directory nil) (defun bbdb-style-file-directory () (or bbdb-style-file-directory (setq bbdb-style-file-directory (file-name-directory (locate-library "bbdb"))))) ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 17:55 ` Stephen J. Turnbull @ 2013-05-30 18:22 ` Eli Zaretskii 2013-05-30 20:47 ` Andreas Schwab 2013-05-31 3:50 ` Stephen J. Turnbull 0 siblings, 2 replies; 38+ messages in thread From: Eli Zaretskii @ 2013-05-30 18:22 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: winkler, emacs-devel > From: "Stephen J. Turnbull" <stephen@xemacs.org> > Date: Fri, 31 May 2013 02:55:49 +0900 > > Ah, I didn't know what bbdb-print does. > > Now that I do, I don't see what's so hard about > > (shell-command (format "TEXINPUTS=%s%s tex %s" > (bbdb-style-file-directory) > (getenv "TEXINPUTS") > file-to-tex)) That it only works with a Posixy shell? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 18:22 ` Eli Zaretskii @ 2013-05-30 20:47 ` Andreas Schwab 2013-05-31 3:50 ` Stephen J. Turnbull 1 sibling, 0 replies; 38+ messages in thread From: Andreas Schwab @ 2013-05-30 20:47 UTC (permalink / raw To: Eli Zaretskii; +Cc: Stephen J. Turnbull, winkler, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: "Stephen J. Turnbull" <stephen@xemacs.org> >> Date: Fri, 31 May 2013 02:55:49 +0900 >> >> Ah, I didn't know what bbdb-print does. >> >> Now that I do, I don't see what's so hard about >> >> (shell-command (format "TEXINPUTS=%s%s tex %s" >> (bbdb-style-file-directory) >> (getenv "TEXINPUTS") >> file-to-tex)) > > That it only works with a Posixy shell? So modify process-environment. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 18:22 ` Eli Zaretskii 2013-05-30 20:47 ` Andreas Schwab @ 2013-05-31 3:50 ` Stephen J. Turnbull 2013-05-31 14:14 ` Tom Tromey 2013-05-31 14:42 ` Ted Zlatanov 1 sibling, 2 replies; 38+ messages in thread From: Stephen J. Turnbull @ 2013-05-31 3:50 UTC (permalink / raw To: Eli Zaretskii; +Cc: winkler, emacs-devel Eli Zaretskii writes: > > From: "Stephen J. Turnbull" <stephen@xemacs.org> > > Date: Fri, 31 May 2013 02:55:49 +0900 > > > > Ah, I didn't know what bbdb-print does. > > > > Now that I do, I don't see what's so hard about > > > > (shell-command (format "TEXINPUTS=%s%s tex %s" > > (bbdb-style-file-directory) > > (getenv "TEXINPUTS") > > file-to-tex)) > > That it only works with a Posixy shell? Last I heard Emacs doesn't have a policy that says that's a showstopper, although it won't stop you from fixing it if you like. Anyway, I'm sure there's a way to work around it with enough effort. I'm just not going to make it. The code above is proof of concept, not a patch submission to Emacs (or BBDB for that matter). The practical deal-breaker for "install in the right place" is that Emacs doesn't "own" the texmf hierarchies, so you can't guarantee that ELPA can install those sources "where they belong" according to tradition or FHS. Given that, I don't see why anybody should care where they are installed, as long as BBDB can find them. Ted Z's proposal for enhancing ELPA packages' ability to find their stuff is a first step in the right direction, I think. But AFAIK there is no spec for *user* FHS. Python has been playing around with ~/.local among others (I think that may be an fd.o draft standard or something?) If that were to become widespread, you could add ~/.local to your kpathsea path, and that would be a big win. Failing that (ie, for the foreseeable future), I think what ELPA should do is provide a suite of functions for finding package resources such as elisp (installed), the source tree, graphics and other multimedia, helper files for external apps (eg, the bbdb-print TeX style files), helper executables, and so on. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-31 3:50 ` Stephen J. Turnbull @ 2013-05-31 14:14 ` Tom Tromey 2013-05-31 18:30 ` Stephen J. Turnbull 2013-05-31 14:42 ` Ted Zlatanov 1 sibling, 1 reply; 38+ messages in thread From: Tom Tromey @ 2013-05-31 14:14 UTC (permalink / raw To: Stephen J. Turnbull; +Cc: Eli Zaretskii, winkler, emacs-devel >>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes: Stephen> Failing that (ie, for the foreseeable future), I think what Stephen> ELPA should do is provide a suite of functions for finding Stephen> package resources such as elisp (installed), the source tree, Stephen> graphics and other multimedia, helper files for external apps Stephen> (eg, the bbdb-print TeX style files), helper executables, and Stephen> so on. It does already. See (info "(elisp) Multi-file Packages"): If the multi-file package contains auxiliary data files (such as images), the package's Lisp code can refer to these files via the variable `load-file-name' (*note Loading::). Here is an example: (defconst superfrobnicator-base (file-name-directory load-file-name)) (defun superfrobnicator-fetch-image (file) (expand-file-name file superfrobnicator-base)) Tom ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-31 14:14 ` Tom Tromey @ 2013-05-31 18:30 ` Stephen J. Turnbull 0 siblings, 0 replies; 38+ messages in thread From: Stephen J. Turnbull @ 2013-05-31 18:30 UTC (permalink / raw To: Tom Tromey; +Cc: Eli Zaretskii, winkler, emacs-devel Tom Tromey writes: > >>>>> "Stephen" == Stephen J Turnbull <stephen@xemacs.org> writes: > Stephen> Failing that (ie, for the foreseeable future), I think what > Stephen> ELPA should do is provide a suite of functions for finding > Stephen> package resources[...]. > > It does already. See [load-file-name]. That assumes that everything is placed in a particular directory, or perhaps in a fixed relative location to that directory. What I have in mind is something that supports more complex (and presumably prettier) package organizations, so that you can do (locate-data-file 'my-package "sjt-face.png") and things like that without assuming that images live in the same directory as the Lisp code. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-31 3:50 ` Stephen J. Turnbull 2013-05-31 14:14 ` Tom Tromey @ 2013-05-31 14:42 ` Ted Zlatanov 1 sibling, 0 replies; 38+ messages in thread From: Ted Zlatanov @ 2013-05-31 14:42 UTC (permalink / raw To: emacs-devel On Fri, 31 May 2013 12:50:51 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: SJT> Ted Z's proposal for enhancing ELPA packages' ability to find their SJT> stuff is a first step in the right direction, I think. Sorry, I don't know what I proposed :) SJT> But AFAIK there is no spec for *user* FHS. Besides ELPA, don't forget el-get. It has its own directory structure by necessity. I don't see a problem with innovation at the user directory level, as long as it doesn't leak into the system software. SJT> I think what ELPA should do is provide a suite of functions for SJT> finding package resources such as elisp (installed), the source SJT> tree, graphics and other multimedia, helper files for external apps SJT> (eg, the bbdb-print TeX style files), helper executables, and so SJT> on. The data link between Emacs and the OS and other software installed within is pretty fragile so I don't think this is an easy integration task. Internally to Emacs it's no problem of course. I think the answer is to reduce dependency on external tools. Emacs can do most things on its own; `bbdb-print' is a very unusual case. Ted ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-29 22:29 ` Stefan Monnier 2013-05-30 7:14 ` Roland Winkler @ 2013-05-30 9:37 ` Ulrich Mueller 2013-05-30 11:24 ` Roland Winkler ` (2 more replies) 1 sibling, 3 replies; 38+ messages in thread From: Ulrich Mueller @ 2013-05-30 9:37 UTC (permalink / raw To: Stefan Monnier; +Cc: Christian Egli, Roland Winkler, emacs-devel >>>>> On Wed, 29 May 2013, Stefan Monnier wrote: >> How do I configure install locations of a package if it's in ELPA >> format? > You don't. Why is this better than having them configurable? Especially, why are you asking that a package like BBDB that has a perfectly working autoconf build system should _remove_ it? >> Especially, if the package has non-lisp components? > You leave them alongside the Elisp files. Emacs itself uses a different layout and keeps non-lisp files in different directories like etc or info. (Hopefully there are no plans to change that?) For example, for Info files it's really a PITA if they're not collected in one (or at least, few) central locations. > And when you need them, your Elisp package will find them by looking > around itself (it can get access to its own location via > `load-file-name'). This means that anyone who wants to adhere to some standard like FHS must move files around manually. I had to do this way too often when packaging things for Gentoo. Most packages are at least friendly enough and spend a defvar or defcustom that allows to configure these directories (often with a fallback to the above-mentioned load-file-name location). Ulrich ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 9:37 ` Ulrich Mueller @ 2013-05-30 11:24 ` Roland Winkler 2013-05-30 12:48 ` Ulrich Mueller 2013-05-30 14:57 ` Ted Zlatanov 2013-05-30 14:37 ` Stefan Monnier 2013-05-30 15:03 ` Ted Zlatanov 2 siblings, 2 replies; 38+ messages in thread From: Roland Winkler @ 2013-05-30 11:24 UTC (permalink / raw To: Ulrich Mueller; +Cc: Stefan Monnier, emacs-devel On Thu May 30 2013 Ulrich Mueller wrote: > Emacs itself uses a different layout and keeps non-lisp files in > different directories like etc or info. (Hopefully there are no plans > to change that?) The problem is really that the TeX files generated by bbdb-print connect two different worlds: The TeX file is generated by emacs that comes with its search path and installation tree. But then this TeX file gets compiled by the TeX command that only knows its own search paths. And all this happens in a user directory so that everything should not depend on the absolute directories used by the particular installations of emacs and TeX. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 11:24 ` Roland Winkler @ 2013-05-30 12:48 ` Ulrich Mueller 2013-05-30 14:57 ` Ted Zlatanov 1 sibling, 0 replies; 38+ messages in thread From: Ulrich Mueller @ 2013-05-30 12:48 UTC (permalink / raw To: Roland Winkler; +Cc: Stefan Monnier, emacs-devel >>>>> On Thu, 30 May 2013, Roland Winkler wrote: > The problem is really that the TeX files generated by bbdb-print > connect two different worlds: Sure, these are the more interesting cases. Other such examples include AUCTeX, SLIME, and Pymacs. Installation is trivial if a package consists of elisp files only. > The TeX file is generated by emacs that comes with its search path > and installation tree. But then this TeX file gets compiled by the > TeX command that only knows its own search paths. > And all this happens in a user directory so that everything should > not depend on the absolute directories used by the particular > installations of emacs and TeX. That's why there are distros that set up things such that different pieces of software fit together, and work for the user out of the box. Of course, it will help if the package is configurable and can adapt to different environments. Ulrich ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 11:24 ` Roland Winkler 2013-05-30 12:48 ` Ulrich Mueller @ 2013-05-30 14:57 ` Ted Zlatanov 2013-05-30 17:11 ` Stefan Monnier 1 sibling, 1 reply; 38+ messages in thread From: Ted Zlatanov @ 2013-05-30 14:57 UTC (permalink / raw To: emacs-devel On Thu, 30 May 2013 13:24:48 +0200 "Roland Winkler" <winkler@gnu.org> wrote: RW> On Thu May 30 2013 Ulrich Mueller wrote: >> Emacs itself uses a different layout and keeps non-lisp files in >> different directories like etc or info. (Hopefully there are no plans >> to change that?) RW> The problem is really that the TeX files generated by bbdb-print RW> connect two different worlds: RW> The TeX file is generated by emacs that comes with its search path RW> and installation tree. But then this TeX file gets compiled by the RW> TeX command that only knows its own search paths. RW> And all this happens in a user directory so that everything should RW> not depend on the absolute directories used by the particular RW> installations of emacs and TeX. This may be quite heretical, but have you considered Markdown for the BBDB docs? No build systems needed; readable as plain text; convertible to many other formats with little work; really easy to learn and use. Emacs can view it. I've been happy with Markdown for personal and work use. The lack of a build system is especially appealing, from experience with installing hundreds of megabytes for the documentation support toolchain for Gnus and BBDB. Ted ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 14:57 ` Ted Zlatanov @ 2013-05-30 17:11 ` Stefan Monnier 2013-05-30 20:31 ` Ted Zlatanov 0 siblings, 1 reply; 38+ messages in thread From: Stefan Monnier @ 2013-05-30 17:11 UTC (permalink / raw To: emacs-devel > This may be quite heretical, but have you considered Markdown for the > BBDB docs? bbdb-print doesn't have anything to do with documentation. It's a function that lets you print your bbdb addressbook via LaTeX. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 17:11 ` Stefan Monnier @ 2013-05-30 20:31 ` Ted Zlatanov 0 siblings, 0 replies; 38+ messages in thread From: Ted Zlatanov @ 2013-05-30 20:31 UTC (permalink / raw To: emacs-devel On Thu, 30 May 2013 13:11:56 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: >> This may be quite heretical, but have you considered Markdown for the >> BBDB docs? SM> bbdb-print doesn't have anything to do with documentation. SM> It's a function that lets you print your bbdb addressbook via LaTeX. D'oh, sorry. Ted ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 9:37 ` Ulrich Mueller 2013-05-30 11:24 ` Roland Winkler @ 2013-05-30 14:37 ` Stefan Monnier 2013-05-30 15:03 ` Ted Zlatanov 2 siblings, 0 replies; 38+ messages in thread From: Stefan Monnier @ 2013-05-30 14:37 UTC (permalink / raw To: Ulrich Mueller; +Cc: Christian Egli, Roland Winkler, emacs-devel >>> How do I configure install locations of a package if it's in ELPA >>> format? >> You don't. > Why is this better than having them configurable? Because that saves you from having to configure it. > Especially, why are you asking that a package like BBDB that has > a perfectly working autoconf build system should _remove_ it? I didn't ask to remove it: it can be kept in the ELPA package. It's just not useful/needed for the usual ELPA style of distribution/installation. >>> Especially, if the package has non-lisp components? >> You leave them alongside the Elisp files. > Emacs itself uses a different layout and keeps non-lisp files in > different directories like etc or info. Indeed. In some cases it was a good choice, in others I'm not so sure. > (Hopefully there are no plans to change that?) It's definitely not important enough to waste time changing it unless there's a good reason for it. > For example, for Info files it's really a PITA if they're not > collected in one (or at least, few) central locations. Why? >> And when you need them, your Elisp package will find them by looking >> around itself (it can get access to its own location via >> `load-file-name'). > This means that anyone who wants to adhere to some standard like FHS > must move files around manually. I had to do this way too often when > packaging things for Gentoo. I don't see any particular reason why you'd feel compelled to break an ELPA package into its constituents and spread them around in different directories, just for the sake of following some standard. If there's a real benefit to it and it's higher than the cost of moving things around, then by all means go for it. But "the ELPA way" is pretty damn convenient and I personally can't think of any benefit you'd get from applying the FHS to it. > Most packages are at least friendly enough and spend a defvar or > defcustom that allows to configure these directories (often with a > fallback to the above-mentioned load-file-name location). In order to be able to use load-file-name, you need to evaluate it during load and save it in some global variable. So, yes, a natural way to do it ends up introducing defvar/defcustoms for that anyway. Stefan ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-30 9:37 ` Ulrich Mueller 2013-05-30 11:24 ` Roland Winkler 2013-05-30 14:37 ` Stefan Monnier @ 2013-05-30 15:03 ` Ted Zlatanov 2 siblings, 0 replies; 38+ messages in thread From: Ted Zlatanov @ 2013-05-30 15:03 UTC (permalink / raw To: emacs-devel On Thu, 30 May 2013 11:37:13 +0200 Ulrich Mueller <ulm@gentoo.org> wrote: >>>>>> On Wed, 29 May 2013, Stefan Monnier wrote: >>> How do I configure install locations of a package if it's in ELPA >>> format? >> You don't. UM> Why is this better than having them configurable? Especially, why are UM> you asking that a package like BBDB that has a perfectly working UM> autoconf build system should _remove_ it? I don't think Stefan asked for that. Simply, when something is installed as an ELPA package, it doesn't have control over its install location. UM> This means that anyone who wants to adhere to some standard like FHS UM> must move files around manually. I had to do this way too often when UM> packaging things for Gentoo. UM> Most packages are at least friendly enough and spend a defvar or UM> defcustom that allows to configure these directories (often with a UM> fallback to the above-mentioned load-file-name location). Installing system packages and installing user packages are completely different things. The ELPA is intended as a user-accessible format, where "user" could be "root". But it doesn't have deep integration with any of the Emacs platforms, nor was that part of its design. I think that's worth discussing further and improving. Ted ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: BBDB v3 approaching release 2013-05-29 16:45 ` Ulrich Mueller 2013-05-29 22:29 ` Stefan Monnier @ 2013-06-01 14:34 ` Steinar Bang 1 sibling, 0 replies; 38+ messages in thread From: Steinar Bang @ 2013-06-01 14:34 UTC (permalink / raw To: emacs-devel >>>>> Ulrich Mueller <ulm@gentoo.org>: >>>>> On Tue, 28 May 2013, Stefan Monnier wrote: >> You *really* want to stick to the ELPA format. It's simple and >> straightforward for you, and for the end-users. > How do I configure install locations of a package if it's in ELPA > format? Especially, if the package has non-lisp components? Just FYI: someone already seems to have done the ELPA bit, because snapshots of the new BBDB is available in MELPA: http://www.emacswiki.org/emacs/ELPA http://www.emacswiki.org/emacs/MELPA http://melpa.milkbox.net/ The BBDB snapshot I installed from MELPA yesterday, has the version number 20130526.1945. ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2013-06-01 14:34 UTC | newest] Thread overview: 38+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-05-27 8:18 BBDB v3 approaching release Roland Winkler 2013-05-27 8:49 ` Leo Liu 2013-05-27 15:13 ` Stefan Monnier 2013-05-27 16:13 ` Roland Winkler 2013-05-27 16:57 ` Stefan Monnier 2013-05-27 19:28 ` Roland Winkler 2013-05-27 19:35 ` Dmitry Gutov 2013-05-27 20:18 ` Roland Winkler 2013-05-28 5:32 ` Ulrich Mueller 2013-05-28 7:49 ` Roland Winkler 2013-05-28 12:34 ` Stefan Monnier 2013-05-27 20:59 ` Stefan Monnier [not found] ` <87obbvwgw6.fsf@sbs.ch> 2013-05-28 21:23 ` Roland Winkler 2013-05-28 22:29 ` Stefan Monnier 2013-05-29 13:27 ` Roland Winkler 2013-05-29 16:45 ` Ulrich Mueller 2013-05-29 22:29 ` Stefan Monnier 2013-05-30 7:14 ` Roland Winkler 2013-05-30 7:57 ` Jambunathan K 2013-05-30 8:04 ` Stephen J. Turnbull 2013-05-30 11:16 ` Roland Winkler 2013-05-30 17:25 ` Stephen J. Turnbull 2013-05-30 17:55 ` Stephen J. Turnbull 2013-05-30 18:22 ` Eli Zaretskii 2013-05-30 20:47 ` Andreas Schwab 2013-05-31 3:50 ` Stephen J. Turnbull 2013-05-31 14:14 ` Tom Tromey 2013-05-31 18:30 ` Stephen J. Turnbull 2013-05-31 14:42 ` Ted Zlatanov 2013-05-30 9:37 ` Ulrich Mueller 2013-05-30 11:24 ` Roland Winkler 2013-05-30 12:48 ` Ulrich Mueller 2013-05-30 14:57 ` Ted Zlatanov 2013-05-30 17:11 ` Stefan Monnier 2013-05-30 20:31 ` Ted Zlatanov 2013-05-30 14:37 ` Stefan Monnier 2013-05-30 15:03 ` Ted Zlatanov 2013-06-01 14:34 ` Steinar Bang
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.