all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: "git describe" in version of info file with "make info_git_describe"
Date: Fri, 28 Oct 2011 11:26:34 +0200	[thread overview]
Message-ID: <87fwidpiut.fsf@Rainer.invalid> (raw)
In-Reply-To: CALn3zohhKO2hGtMbqbAGN4LyUf_W1izg2J_jRXV4ySDm9Q5Ztw@mail.gmail.com

Michael Brand <michael.ch.brand@gmail.com> writes:
> 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?

I don't know if it is still used by the maintainers for preparing a
release.  I do know that there are no version numbers in the source
files any more, so that part of set-version.pl surely is obsolete.  The
other parts may become obsolete if whatever is still in used can be
moved to make.  I've already started to reduce the reliance on perl in
my branch, switching to sed where possible.

> 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.

Again I don't know if or when this gets merged.  I've already used up my
TINYCHANGEs and hit an impasse with the FSF papers that I don't know how
to resolve... :-(  Then again, the build system doesn't really become
part of Emacs, but it's up to the maintainers to decide.

> 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.

I'd much prefer to inject the version in a different way, not making an
altered copy that the build works from.  The result is the same, but it
doesn't feel OK... so probably the solution should be to get the version
injected via some @set in an @include file (that's the recommended way
from the Texinfo perspective, anyway) that is produced by make whenever
the source file changes.

> 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.

I posit that if it's worth to have that (I'd say yes), ``make info´´
should do that, in a way that is compatible with version control.
Anyway, I've implemented the requested functionality into my Makefile
fork, please test.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

  reply	other threads:[~2011-10-28  9:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02 14:11 "git describe" in version of info file with "make info_git_describe" Michael Brand
2011-06-02 14:47 ` Bernt Hansen
2011-06-02 15:05   ` Michael Brand
2011-06-02 19:36     ` Michael Brand
2011-10-16 19:12       ` Michael Brand
2011-10-21 14:44         ` Carsten Dominik
2011-10-21 16:13           ` Bernt Hansen
2011-10-23 22:50             ` Bernt Hansen
2011-10-26 16:07           ` Michael Brand
2011-10-26 16:56             ` Achim Gratz
2011-10-27 18:24               ` Michael Brand
2011-10-28  9:26                 ` Achim Gratz [this message]
2011-10-29 11:40                   ` Michael Brand
2011-10-30  7:01                     ` Achim Gratz
2011-10-30 14:20                       ` Michael Brand

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=87fwidpiut.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=emacs-orgmode@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.