From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: Correct Paths to Emacs C Sources after Installation Date: Tue, 04 Nov 2014 17:45:03 +0200 Message-ID: <83y4rrug00.fsf@gnu.org> References: <834mugvw5w.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1415115943 21998 80.91.229.3 (4 Nov 2014 15:45:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Nov 2014 15:45:43 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 04 16:45:36 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XlgIY-0006cA-L1 for geh-help-gnu-emacs@m.gmane.org; Tue, 04 Nov 2014 16:45:34 +0100 Original-Received: from localhost ([::1]:41251 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlgIY-0000um-AD for geh-help-gnu-emacs@m.gmane.org; Tue, 04 Nov 2014 10:45:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlgII-0000rx-Gi for help-gnu-emacs@gnu.org; Tue, 04 Nov 2014 10:45:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlgIC-00025R-LB for help-gnu-emacs@gnu.org; Tue, 04 Nov 2014 10:45:18 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:47038) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlgIC-000256-Dt for help-gnu-emacs@gnu.org; Tue, 04 Nov 2014 10:45:12 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NEI00I00UBRCG00@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Tue, 04 Nov 2014 17:45:10 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NEI00IL1UF92H50@a-mtaout22.012.net.il> for help-gnu-emacs@gnu.org; Tue, 04 Nov 2014 17:45:10 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:100733 Archived-At: > Date: Tue, 4 Nov 2014 00:05:47 +0100 > From: Alexander Shukaev > Cc: help-gnu-emacs@gnu.org > > 1. I build and install Emacs for personal usage. Does not even matter on > what platform Unix-like or Windows. Sources are not installed by default, > but I believe their either should or at least an option has to be provided > for that. No other project does that, so Emacs is not an exception here, but rather the rule. It is OK to do that in your special case, of course, but you are lobbying for the project to cater to such a special use case, which I personally am not convinced is justified. See below. > Usually build directories are temporary and so after deleting it, > one would not be able to browse C sources interactively. "Usually", users don't need to browse the sources to understand what the function/variable does and how to use it. The only reasons for this information not to be found in the doc string itself are: (a) documentation bugs, for which you are kindly requested to file bug reports; and (b) aspects the developers deliberately decided not to document because they are internal details that are not supposed to be exposed to Lisp, and are frequently subject to change without notice. I understand that you have some project in mind where you would like the C source-level code be available, but that is a very special use case. > Furthermore, it is conceptually "stupid" to separate > sources from built Emacs when, in fact, this built Emacs wants to refer to > these sources it was built from. I think nobody can deny that it's pretty > much a convention to distribute open-source project sources under > ".../src/name" (for potential further usage or reference like we have in > this case as well). You are mixing 2 unrelated issues: (1) the legal requirement of the GPL to provide users with sources that were used to build a distributed binary, and (2) whether or not to have those sources installed on the end-user machines. The former requirement is satisfied by having a source tarball near the binary one; then users who want to study or modify the Emacs sources can unpack the sources and point source-directory to where they unpack it. The latter requirement doesn't exist in most cases, it is something you need for your specific project. > 2. I build and install Emacs, then I package it and distribute to end > users. Why on Earth should the path to the build directory (which obviously > does not exist on end users' machines) that I used be hard coded into > "Vsource_directory"? And again this leads us to the same argument as in #1. You can provide a site-init file with that distribution that redirects source-directory to where the sources will be after installing the distribution. Once again: the defaults are for the majority. Situations that don't fit the "usual" use cases are handled by customizing Emacs. I submit that Emacs allows you to customize it even for your unusual use case.