autorevision extracts metadata about the head version of your repository. This program is meant to be used by project build systems to extract properties that can be used in software version strings. It can create files containing variable and macro definitions suitable for C, C++, sh, Python, Perl, PHP, lua, Javascript, and header files suitable for use with preprocessing Info.plist files.
This was a sort of spinoff from irker, though I’ve decided it not to use it there because I want to keep irkerd and irkerhook.py in single self-contained files.
No, I don’t know dak180’s real name. He’s a pretty good collaborator, though.
link?
Isn’t it customary to include a link to access software that you’re announcing? Google tells me https://github.com/Autorevision/autorevision.git — which I assume is correct :)
>Isn’t it customary to include a link to access software that you’re announcing?
Yes, it is. Paste error, now fixed.
Why, thank you.
>Why, thank you.
You were very patient with my feline-induced sleep deprivation. :-)
Hi Eric, just a heads-up: you may wanna change the link to the github site used on your autorevision site to use the http protocol, right now it uses the git protocol making clicking on it in a browser fail :)
If it is bash script, why not use advanced bash features for variable manipulation (extension of POSIX like ${var%sth}) instead of calls to ‘sed’ and ‘cut’ etc., which is a bit slower (especially on MS Windows)?
@Jakub
That would make things quite a bit more brittle and frankly more difficult to maintain. When I see those ‘advanced’ kinds of shell features I want to run away in horror, for I know I am then in for a long day of man page scouring. sed, cut, and such are easily grokked, and on sane operating systems are not slower enough to warrant use of shell arcana.
In other news, is this ( http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/ ) relevant to the bufferbloat project?
Conversely, if it’s _not_ going to use those advanced features, why is it a bash script?
This actually happens to be relevant to a project where I work, where much more primitive functionality on a similar level is done.
As a result I’ve already added a pull request for Java support. :)
Mostly for the test statements.
>Mostly for the test statements.
I would have written it in Python, myself. But it’s dak180’s project, and thus his choice of language.
sed, cut, and such are easily grokked
“… now you have two problems”.
(Though to be fair, deep custom BASH is its own little hell.)
“Mostly for the test statements.” – Which of the test statements can’t you do in normal sh? I see you’re using the double-bracket [[ operator, but it looks like most of the actual tests are standard ones that can be done just as well with the standard single bracket [ command.
I have found that when you need to have more than one in the same if statement, as an example, using [ instead of [[ can lead to odd failures that give me massive headaches. It is easier to not have to deal with them.
There appears to be a bug in the hg repo code; my hg on two different machines is complaining that the “hg –color” option is not recognized. That hg option occurs in the pipeline that generates the VCS_TAG variable. The only way I can get the script to run without error is to delete the offending sed option entirely; I’m not sure if that’s OK for full functionality. I don’t have time right now to generate a pull request on github, but I’ll try to do so later tonight.
> my hg on two different machines is complaining that the “hg –color” option is not recognized
I should add that I’m using mercurial version 2.x on both machines.
It has nothing to do with the version of hg; for a quick fix you can activate the color extension or you can use the git tip where I have just committed a fix.
> It has nothing to do with the version of hg; for a quick fix you can activate the color extension or you can use the git tip where I have just committed a fix.
Tried both of these and both worked fine, thanks!
@dak180
I think it’s a very nice bash script.
A couple of style points: since you’re using bash, it’s better for readability, IMHO, to use heredocs with the form “<<-EOF", which allows you to inserts TAB characters, which won't get output, but allow you to indent naturally. Also, you don't need quotes when using the [[ ]] tests, that's one of the points of using a [[ ]] test. :)
Now a couple of functionality points: I haven't examined the code thoroughly, but like Jakub, I noticed heavy use of tools like grep and sed. Unless you are using purely POSIX-standard switches (i.e., no GNU-specific switches), users running the script on BSD or Solaris will have trouble as the OS-bundled tools will tend to be first in the path, if they have the GNU versions installed at all. I suppose a competent BSD user or Solaris admin will know instinctively how to deal with this, but it might be helpful to include some code that at least checks to see if the grep that's in the PATH is GNU grep if you're going to require it.
But I'm probably just picking nits.
Also, I agree with @esr: Python would have been way easier, IMHO. My rule is that when a bash script exceeds about a couple of 50-line screenfuls in my text editor, it's time to rewrite it in Python.
Since the sed that i am normally using is the BSD sed I will be rather surprised if it does not work; as for grep the only two flags that get used are ‘-v’ and ‘-q’, according to the docs those should work too.
I might rewrite it in Python at some point when I know Python better.
Nb. I would use Perl rather than Python… but to each its own.
Besides there are I think Python API for both Mercurial and Bazaar (but I might be mistaken).
> Besides there are I think Python API for both Mercurial and Bazaar (but I might be mistaken)
There certainly is for Mercurial since it’s written in Python. There also is a Python library for subversion, and the Dulwich Python implementation of git. I don’t know about bzr since I don’t use it.
> There certainly is for Mercurial since it’s written in Python. There also is a Python library for subversion, and the Dulwich Python implementation of git. I don’t know about bzr since I don’t use it.
Dulwich is a reimplementation of git, so the question is how complete is it, and whether functions required by autorevision are implemented. There is also pygit2, Python bindings to libgit2, a linkable library for Git still in early development.
Bazaar (bzr) is pure Python, IIRC (Mercurial has parts written in C for performance).
> Bazaar (bzr) is pure Python, IIRC (Mercurial has parts written in C for performance).
Bazaar is pure Python, with optional C-based implementations of some modules for performance. In other words, you can run it without compiling any C source code, but it will be slower.
WHAT??? NO support for Intercal? This program is a piece of shit, obviously.
We are accepting patches. ?