[darcs-devel] darcs patch: automatically generate version string fr... (and 2 more)

David Roundy droundy at darcs.net
Tue May 24 05:52:55 PDT 2005


On Mon, May 23, 2005 at 02:15:01PM +0200, Tomasz Zielonka wrote:
> Hello!
> 
> Here is a proof-of-concept patch that aims to reduce the hassle
> associated with maintaining the darcs_version string by hand. In
> current form it's not ready for inclusion in darcs-unstable (I don't
> like everything and I'd like to split it to smaller patches).  I'll have
> some time to work on this in the evening and I thought that if I sent it
> here I can get some comments from you in the meantime.

Good idea!

>  - module Version can't be imported in any of COMMON_FILES (chicken
>    and egg problem), so I changed the interface of External.sendEmail
>    and External.sendEmailDoc to explicitly take the version string
>    as first parameter (see below for an improvement idea)

Couldn't we perhaps bootstrap somehow to avoid the chicken and egg problem?
For example, could we create Version.lhs at configure time rather than in
the makefile? Certainly it's easy enough to create an "unknown"
Version.lhs.  The downside would be that the (+ 13 patches) would then get
out of date, since it wouldn't be updated with each compile.

Hmmmm.  It seems like there ought to be a way around this.  One option
would be to do something more similar to how we generate Context.hs: we
could parse the output an existing darcs (with "." in the path for
bootstrapping) to generate Version.hs.  I imagine something like

darcs changes -t ^1.0 --reverse | tail -1 | cut -d ' ' -f 4

to find the version number and

darcs changes --from-tag ^1.0 | grep '^  \*' | wc -l

to find out how many extra patches there are.

This would be crude, but would allow you to break the chicken/egg cycle by
bootstrapping with an existing darcs binary.  And users without an existing
darcs binary are using a tarball, in which case they just use the
precomputed Version.hs (or alternatively, a precomputed VERSION).

I have no idea how problematic the above tail, cut, grep and wc would be in
windows, but we could easily enough write a little haskell program to do
the equivalent.

Also note that --from-tag already handles unordered tags properly... which
makes me wonder whether it might make sense to rewrite make_changes proper
to also call darcs directly.  It's not a bad idea to use darcs' existing
interface in our helper programs--where it's inadequate, it would be worth
fixing to *be* adequate.
-- 
David Roundy
http://www.darcs.net




More information about the darcs-devel mailing list