From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4174 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Feature request Date: Tue, 29 Oct 2013 17:30:30 -0400 Message-ID: <20131029213030.GZ20515@brightrain.aerifal.cx> References: <20131029023312.GR20515@brightrain.aerifal.cx> <526F21F5.2010806@gentoo.org> <20131029045454.GU20515@brightrain.aerifal.cx> <526FC4E9.20206@bradfordembedded.com> <20131029185338.Horde.9cKxLtAfJC2GguRQUWZZYA1@ssl.eumx.net> <20131029192343.GO1685@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1383082239 11675 80.91.229.3 (29 Oct 2013 21:30:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 29 Oct 2013 21:30:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4178-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 29 22:30:44 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VbGs8-0007df-4u for gllmg-musl@plane.gmane.org; Tue, 29 Oct 2013 22:30:44 +0100 Original-Received: (qmail 7333 invoked by uid 550); 29 Oct 2013 21:30:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7325 invoked from network); 29 Oct 2013 21:30:43 -0000 Content-Disposition: inline In-Reply-To: <20131029192343.GO1685@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4174 Archived-At: On Tue, Oct 29, 2013 at 08:23:43PM +0100, Szabolcs Nagy wrote: > * Kurt H Maier [2013-10-29 18:53:38 +0000]: > > Quoting Andrew Bradford : > > >How often is this a concern? > > >How are people obtaining non-release source trees not via an scm tool? > > > > > > > By pulling on one machine and copying it to various build hosts. The > > fewer build dependencies, the better. > > > > or building in a chroot > or in qemu from a v9fs mount > ... > > the build should not fail if git is unavailable Exactly. > otherwise the version string is not critical in that case > (if it's a make variable then it can be overridden from > config.mak or from the make cmdline anyway) It's not _critical_, but if it's horribly wrong, that defeats the purpose of being able to determine the version installed. Perhaps a good fallback approach would be: 1. Have a version file which always contains the most recent released version (i.e. it's updated in the tagged commit for the release). 2. At build time, if git is available and .git exists, use git describe to construct the version string. 3. Otherwise, use the version file (from #1 above), and if .git exists, append -unknown-git or similar to it so that it's clear that there may be changes beyond what was in the release. Clearly the version string should make it into the dynamic linker's usage output, but is there anywhere else it should be visible (such as a string in static binaries, or a confstr() string)? I don't want to go adding bloat that makes users mad, but it also may be frustrating not to know what version a binary was linked with, so I think this is a question that merits some discussion. Rich