can't build stable normally-numbered versions anymore?

[dchmelik]

Describe the issue

Can't build stable normally-numbered versions anymore: forced to use git?

Can you reliably reproduce the issue?

If so, please list the steps to reproduce below:

1. Get latest stable normally-numbered version.
2. Compile.
3. Crash with line 'fatal: not a git repository (or any of the parent directories): .git' (then other stuff.)

Expected behaviour

Tell us what should happen

Let people use normally-numbered versions like they always could.

Actual behaviour

Tell us what happens instead

One may be forced to use git.

What version of bitcoin-abc are you using?

List the version number/commit ID, and if it is an official binary, self compiled or a distribution package such as PPA.

0.21 (Well, still have an earlier version and may be forced to use git, whatever version that's at...)

[jasonbcox]

What command(s) are you using to compile? There's not enough information here to reproduce.

And what do you mean by "normally numbered" version?

[jasonbcox]

170ea4f fixes some confusing error messages that you might encounter while trying to build without the .git directory being present. Although the build was succeeding, you may have seen a "fatal" error message that did not affect the build. Is this related to your issue?

[dchmelik]

'Compile:' 'doc/build-unix.md: To Build'. In the past I might've used arguments/flags/switches (such as '--program-suffix' and) that file mentions (which I understood as allowed without mentioning) such as to exclude libqrencode and/or miniupnpc (and some bitcoin forks needed to let you use an 'incompatible,' newer Berkeley db, but that's less so; don't see it recent doc/build-*.) Now in fact I installed all dependencies (even though unsure I need libzm3, miniupnpc, and don't think I need libqrencode) so in this case when I say 'compile,' I mean build exactly as in instructions: no arguments/flags/switches, except this time not getting to the installation step. Of course, if I didn't have optional dependencies and didn't disable them, that'd have been entirely different errors (than about git) which I learned/memorized all those in the past and can notice similar ones.

This time 0.21.1 compiled fine (without the git error) but I am unable to install & test (because of other issue: no longer seem to be able to '--program-suffix,' so would overwrite original (BTC) bitcoin-qt.)

Decimal numbers in order are normal; for some older programmers and for average users, hexadecimal numbers out-of-order (in relation to numbering software releases) are abnormal. Decimals usually mean what are considered stable software releases (except with alpha or beta) and hexadecimal numbers are assumed to mean often unstable software or at least updates that are still being tested, or at least updates that aren't necessarily a big enough change (to update to) if decimal numbers are still seriously used, until project maintainers tell people any of that isn't the case... like some projects (one IRC bot) claim hourly/daily git commits named hexadecimal hashes are stable, but then switch back to every few months making releases named decimals... the difference being changes finalized after longer have usually had a chance to be tested so people may really have experienced the software as stable for a long time. Though often when projects say less frequent hash-numbered commits are stable, it's the case, occasionally I've found projects (some chat program) to release a patch minutes after someone reports something, resulting in a mistake/bug found, then they release another one a few minutes later. Though often projects' decimal-numbered releases are stable, some have just been completely broken (one kernel) and the maintainers admit it and chew out a code-submitter, but it seems less common. For me it's not completely which releases of projects are often more stable (decimal) or development/testing/unstable (hexadecimal hash) but that deliberately-named decimal releases count in order, and auto-generated hexadecimal-hash releases don't count in order, so when one looks back, one has no idea which is which... and since they may happen so fast or informally or with different people submitting such patches around same time, they probably can't be in order (besides probably being a hash of the archive contents) when merged... so I never have any idea what changed or might be stable until there's a decimal-numbered version (presumably which had significant debugging/testing) or when users have been testing a hash-numbered version a year or more.

I'm not criticizing anyone on GitHub for making hexadecimal-hash-named releases (except when that's all they do then ignore, blame & threaten you for reporting bugs with decimal-numbered tarballs, then admit they don't use those, and it's GitHub's & your fault for autogenerating (broken) & reporting, as a certain other project did; ) just I consider it abnormal, because don't know what to expect with those, nor how to know the chronological order of ones I downloaded. A lot of projects release hexadecimal-hash-named versions that work fine, just I wouldn't be able to make an operating system distribution's build/installation script for such software in a normal way either. I don't for cryptocurrencies, but for some other software only if they don't make too many hexadecimal-hashed-named commits too fast to know what to expect... and as hash-numbered versions confuse some/many users who use automation of build/install scripts, of course I'm hoping for decimal-numbered versions of such other projects.

Anyway; thanks for fixing it... not sure why it worked for a decimal-numbered version before the hash-numbered version, but it did. I can still test the particular hash-numbered commit if you want, though I supposed I'd have to 'rm -rf .git'(?)... (usually one would need to 'chmod -R o+w' or 'sudo rm -rf,' but since the latter is dangerous (and as I use an alias or script, 'rmtree' instead to ask confirmation to rm directories if writable, zero thanks to git & GitHub design on preventing you writing your own files) I have a 'git clone' shell function that chmods...