From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Brand Subject: Re: "git describe" in version of info file with "make info_git_describe" Date: Thu, 27 Oct 2011 20:24:51 +0200 Message-ID: References: <87fwnse1d8.fsf@norang.ca> <87fwifwv1s.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016367fa52a6fa40804b04be312 Return-path: Received: from eggs.gnu.org ([140.186.70.92]:58223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJUdL-0001Zk-0I for emacs-orgmode@gnu.org; Thu, 27 Oct 2011 14:24:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RJUdJ-0001gd-J1 for emacs-orgmode@gnu.org; Thu, 27 Oct 2011 14:24:54 -0400 Received: from mail-ww0-f49.google.com ([74.125.82.49]:57438) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RJUdJ-0001gL-Be for emacs-orgmode@gnu.org; Thu, 27 Oct 2011 14:24:53 -0400 Received: by wwf27 with SMTP id 27so3586592wwf.30 for ; Thu, 27 Oct 2011 11:24:51 -0700 (PDT) In-Reply-To: <87fwifwv1s.fsf@Rainer.invalid> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Achim Gratz Cc: emacs-orgmode@gnu.org --0016367fa52a6fa40804b04be312 Content-Type: text/plain; charset=ISO-8859-1 Hi Achim Thank you for your review. On Wed, Oct 26, 2011 at 18:56, Achim Gratz wrote: > The set-version.pl file may be obsolete (perl is still required), If set-version.pl would be obsolete my patch would be much shorter and I would use something even more portable than perl to change the version in /tmp/org.texi like the POSIX/SUS ed command, used inline in the Makefile. Would you agree? > there is no version number in the individual lisp files anymore. For > installation I've already added a replacement of the version cookie in > org.el with git-describe in my own fork of org-mode ([1] - I don't know if > you've checked it). It would be easy to do the same for org-texi, > albeit before compilation, not only during install. I can remember some discussion but haven't realized that the outcome is a pending merge. Hence I declare version 2 of my patch as "Changes Requested" on patchwork (can't change this myself) and will rebase it against your changes. > I agree it would be useful to have the full version recorded in the > resulting manual, but you really cannot alter the source file (git > status would always be dirty or the version would be wrong, wouldn't it? > :-). Yes, good point. I was aware of that and therefore for the target "info-vg", doc/org.texi is copied to /tmp/org.texi, altered only there and makeinfo reads from there. And I _added_ the target "info-vg" because implementing the same functionality in the target "info" itself, by either adding an auto-detect whether git describe is available (like org-version does) or using org-version itself, is not an option. One still needs to have the unchanged target "info" to build a release with the info version not possibly influenced by git describe. Michael --0016367fa52a6fa40804b04be312 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Achim

Thank you for your review.

On Wed, Oct 26, 2011 at 18:56, Achim Gratz <Stromeko@nexgo.de> wrote:
> The set-version.pl file may be o= bsolete (perl is still required),

If set-version.pl would be obsolet= e my patch would be much shorter and I would use something even more portab= le than perl to change the version in /tmp/org.texi like the POSIX/SUS ed c= ommand, used inline in the Makefile. Would you agree?

> there is no version number in the individual lisp files anymore. Fo= r
> installation I've already added a replacement of the version cooki= e in
> org.el with git-describe in my own fork of org-mode ([1] - I don't= know if
> you've checked it). =A0It would be easy to do the same for org-tex= i,
> albeit before compilation, not only during install.

I can remember some discussion but haven't realized that the outcome= is a pending merge. Hence I declare version 2 of my patch as "Changes= Requested" on patchwork (can't change this myself) and will rebas= e it against your changes.

> I agree it would be useful to have the full version recorded in the=
> resulting manual, but you really cannot alter the source file (git
> status would always be dirty or the version would be wrong, wouldn'= ;t it?
> :-).

Yes, good point. I was aware of that and therefore for the target "= info-vg", doc/org.texi is copied to /tmp/org.texi, altered only there = and makeinfo reads from there.

And I _added_ the target "info-vg" because implementing the sa= me functionality in the target "info" itself, by either adding an= auto-detect whether git describe is available (like org-version does) or u= sing org-version itself, is not an option. One still needs to have the unch= anged target "info" to build a release with the info version not = possibly influenced by git describe.

Michael

--0016367fa52a6fa40804b04be312--