* Re: Emacs trunk binary on Dropbox
2013-10-01 16:08 ` Dani Moncayo
@ 2013-10-01 16:22 ` Lennart Borgman
2013-10-01 16:36 ` Andreas Schwab
2013-10-01 17:48 ` Eli Zaretskii
2013-10-02 3:00 ` Stephen J. Turnbull
2 siblings, 1 reply; 6+ messages in thread
From: Lennart Borgman @ 2013-10-01 16:22 UTC (permalink / raw)
To: Dani Moncayo; +Cc: Sebastien Vauban, Eli Zaretskii, Emacs-Devel devel
[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]
Must not that revision number be available somewhere in the mirror?
On Oct 1, 2013 6:09 PM, "Dani Moncayo" <dmoncayo@gmail.com> wrote:
> >> Anyway, if you want to know the bzr revno associated with a binary,
> >> just look at the archive name, as explained in the file
> >> "snapshots/README":
> >>
> >> The archives in this directory are named according to this pattern:
> >>
> >> emacs-rREVNO-YYYYMMDD-API-bin.zip
> >>
> >> where:
> >> * REVNO is the bzr revision (of the trunk branch) that was built.
> >> * YYYYMMDD is the commit date of the above revision.
> >> * API is the host OS API (always "w32" for now).
> >
> > That's too bad, because now report-emacs-bug will not show the bzr
> > revision, and whoever reads the bug report has no idea from which zip
> > file the binary came.
> >
> > Please reconsider the decision, or provide some way for your builds to
> > report the bzr revision. TIA.
>
> It would be nice if I could specify the bzr revno manually, for
> example as a parameter to "configure" or "make", because having to
> keep using bzr just for this little thing would also be too bad.
>
> --
> Dani Moncayo
>
>
[-- Attachment #2: Type: text/html, Size: 1633 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs trunk binary on Dropbox
2013-10-01 16:22 ` Lennart Borgman
@ 2013-10-01 16:36 ` Andreas Schwab
0 siblings, 0 replies; 6+ messages in thread
From: Andreas Schwab @ 2013-10-01 16:36 UTC (permalink / raw)
To: Lennart Borgman
Cc: Sebastien Vauban, Eli Zaretskii, Emacs-Devel devel, Dani Moncayo
Lennart Borgman <lennart.borgman@gmail.com> writes:
> Must not that revision number be available somewhere in the mirror?
$ git notes show d079fb16c40905c3ebb5a53483dc17eb85d1577b
monnier@iro.umontreal.ca-20131001155253-f13ed73lrl2p8utj
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs trunk binary on Dropbox
2013-10-01 16:08 ` Dani Moncayo
2013-10-01 16:22 ` Lennart Borgman
@ 2013-10-01 17:48 ` Eli Zaretskii
2013-10-02 3:00 ` Stephen J. Turnbull
2 siblings, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2013-10-01 17:48 UTC (permalink / raw)
To: Dani Moncayo; +Cc: sva-news, emacs-devel
> Date: Tue, 1 Oct 2013 18:08:42 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Sebastien Vauban <sva-news@mygooglest.com>,
> Emacs development discussions <emacs-devel@gnu.org>
>
> > That's too bad, because now report-emacs-bug will not show the bzr
> > revision, and whoever reads the bug report has no idea from which zip
> > file the binary came.
> >
> > Please reconsider the decision, or provide some way for your builds to
> > report the bzr revision. TIA.
>
> It would be nice if I could specify the bzr revno manually, for
> example as a parameter to "configure" or "make", because having to
> keep using bzr just for this little thing would also be too bad.
You need to set the value of emacs-bzr-version (a string) during
dumping.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Emacs trunk binary on Dropbox
2013-10-01 16:08 ` Dani Moncayo
2013-10-01 16:22 ` Lennart Borgman
2013-10-01 17:48 ` Eli Zaretskii
@ 2013-10-02 3:00 ` Stephen J. Turnbull
2 siblings, 0 replies; 6+ messages in thread
From: Stephen J. Turnbull @ 2013-10-02 3:00 UTC (permalink / raw)
To: Dani Moncayo
Cc: Sebastien Vauban, Eli Zaretskii, Emacs development discussions
Dani Moncayo writes:
> It would be nice if I could specify the bzr revno manually, for
> example as a parameter to "configure" or "make", because having to
> keep using bzr just for this little thing would also be too bad.
I don't own the code so won't quote it here, but XEmacs has a file
named "version.sh" which contains mostly static information about the
version: current major and minor, most recent patchlevel, beta status,
and something called "extra version info". I forget how it's done (I
think it's in configure) but if hg is available, just do "hg id -i -n
>> version.sh", and then make includes that file so that the version
values are available in Make variables. They may also be substituted
into config.h, I forget. The latter would probably be easiest: add
a "version-extra-info" building variable to Lisp (in C), and add
#define VERSION_EXTRA_INFO @@VERSION_EXTRA_INFO@@
to config.h.in, and let configure do its thing using the bzr revision
number or revision id or both (I prefer both since people using bzr
who are off the mainline with local changes won't have useful revnos).
If you use a shell/make script, the tricky part is that it's essential
that the "extra_version_info=" line be last and unterminated with a
newline.
Presumably some similar could be done with lisp/version.el or
whatever as well.
I don't see why the maintainers would object to this, so feel free to
come up with a patch.
^ permalink raw reply [flat|nested] 6+ messages in thread