autoreconf on OpenBSD fails with 'sh: tools/git-version.sh: No such file or directory'

[anatoli26]

@elliefm,

When running autoreconf -fiv in cyrus-imapd folder on OpenBSD to generate configure, I get the following errors:

autoreconf-2.69: Entering directory `.'
autoreconf-2.69: configure.ac: not using Gettext
autoreconf-2.69: running: aclocal --force -I cmulocal
sh: tools/git-version.sh: No such file or directory
configure.ac:81: error: AC_INIT should be called with package and version arguments
/usr/local/share/aclocal-1.16/init.m4:171: AM_INIT_AUTOMAKE is expanded from...
configure.ac:81: the top level
 
autom4te-2.69: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: echo failed with exit status: 1
autoreconf-2.69: aclocal failed with exit status: 1

The same on Linux works well. The tools/git-version.sh is there.

What could be wrong?

[elliefm]

The first line of tools/git-version.sh is #!/bin/bash

My vague recollection is that maybe the BSD's install bash somewhere else (/usr/bin/bash? /usr/local/bin/bash?). If this is the case, then I think it's complaining that it is unable to find "/bin/bash" to execute the script.

I've just had a look at the script and I don't think it's bash-specific, though it's been a long time since I've used an sh that wasn't secretly bash or bash-compatible, so I no longer really remember which things are bash-isms and which are bourne. But if you change that line to #!/bin/sh and it works, then we can probably do the same thing upstream

[anatoli26]

@elliefm, thanks for the tip, it was this.

In OpenBSD bash is not installed by default and when it's installed, it's located at /usr/local/bin/bash. I changed the git-version.sh script to use /bin/sh and it worked fine!

I can submit a PR if you prefer with this change. My idea is to include this change in 3.2 so I can change the port to use the autotools to rebuild configure script & co (currently it uses configure included in the tarball).

[elliefm]

Why do you want to rebuild configure? You'll need a bunch of additional build-time dependencies if you do that; the point of including configure in the tarball is to make life easier. If you're rebuilding configure anyway, you might as well build direct from git sources instead of the tarball...

I'll just fix the git-version.sh myself, cause I'll also need to fix it on all the other branches that use it too, and dealing with pull requests for it would be more work than just making the change! :)

[elliefm]

Fixed, and cherry-picked to the other branches that needed it

[anatoli26]

Fixed, and cherry-picked to the other branches that needed it

Thanks!

Why do you want to rebuild configure?

At this time to test easier the changes to configure.ac and related files. And actually if it works correctly, why not to rebuild?

With respect to tarball vs git sources, there should be a sha hash of the sources to check their validity.