From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: "Roland Winkler" <winkler@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: BBDB v3 approaching release
Date: Fri, 31 May 2013 02:25:46 +0900 [thread overview]
Message-ID: <877gigcrc5.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <20903.13593.858294.636072@gargle.gargle.HOWL>
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.
next prev parent reply other threads:[~2013-05-30 17:25 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877gigcrc5.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=winkler@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.