Build Process Fails with "/bin/clang-tidy: No such file or directory"

[criticaltv]

Describe the bug

When attempting to run make -C srv-shared to build on Ubuntu, the process fails with an error, due to not being able to find bin/clang-tidy.

I tried sudo apt install clang-tidy, but that didn't work.

To Reproduce

Follow the commands from the OrchidTechnologies/orchid README (at commit hash 3e075dd368c799ae3598f474e73c89daa3ef75b1)

Also install clang, make and git per this PR.

Also install libc++-dev

Expected behavior

I expect it should complete, and build the software, perhaps with a few more missing sudo apt install commands for missing things.

Device information:

• OS: Ubuntu 19.10

Additional context

Full log:

ubuntu@critical-tv:~/orchid$ make -C srv-shared
make: Entering directory '/home/ubuntu/orchid/srv-shared'
[CT] lnx/x86_64 p2p/source/baton.cpp
/bin/bash: line 2: /bin/clang-tidy: No such file or directory
env/output.mk:159: recipe for target 'out-lnx/x86_64/./p2p/source/baton.cpp.o' failed
make: *** [out-lnx/x86_64/./p2p/source/baton.cpp.o] Error 127
make: Leaving directory '/home/ubuntu/orchid/srv-shared'

[saurik]

This issue has been fixed. Normally, we always cross compile using an installed copy of the Android NDK compiler and a sysroot built using docker, to allow the binary to run on older distributions of Linux, but to allow for just "build and run on your computer" to work I've fixed the Linux build and added this build configuration (as orchid-lnx-bad) to the GitHub workflow CI regression set so I will know if this is broken again in the future.

[criticaltv]

Thanks @saurik I will try this again.

[chrishobcroft]

@saurik please would you review and if appropriate, merge this PR.

[saurik]

@chrishobcroft That documentation is controlled by @nhandler, not me... like, if it were up to me, I'd probably just delete that documentation and replace it with one sentence that says "install the usual set of core development tools plus rust, python3, and meson+ninja; note that you will need a recent version of clang, preferably 9+", as: 1) a developer (as opposed to a user) should already know how to install basic development tools; 2) people use lots of different environments and we can't possibly document all of them; 3) we should not be maintaining replicated copies of the installation instructions that have to be kept up to date for every dependency; and 4) I've already gotten explicit complaints from people that we are recommending specific distributions and environments (in particular, someone was quite angry that we are recommending the usage of homebrew, which was a complaint I felt deeply despite having recently "given in": I now am one of those annoying users of homebrew).

[saurik]

(To be clear, though, it isn't up to me probably for good reason: that's why we have @nhandler, who is sadly busy with other things... likely not by his choice, as I think he would much prefer handling stuff like this ;P/:(. I'm only responding at all because I was directly poked.)

[chrishobcroft]

Github has a "Poke" function. Interesting.

[chrishobcroft]

@saurik wrote:

if it were up to me, I'd probably just delete that documentation and replace it with one sentence that says "install the usual set of core development tools plus rust, python3, and meson+ninja; note that you will need a recent version of clang, preferably 9+"

You could do this, sure. But this tends towards making your software the reserve of "the developers". While they are the purest form of digital artist, I propose that we need fewer technocracies in crypto, not more.

1) a developer (as opposed to a user) should already know how to install basic development tools;

This approach would, for example, fail to provide me (not "a developer", but with a little devOps skill, a Computer Science Masters degree, and a lot of cryptoeconomic awareness), the opportunity to learn, and more importantly then teach this system that you and I both own.

With this opportunity, I have "a starting point", from which to delve "permissionlessly" into this world, and respond to the crypto-economic incentives from the protocol :)

Without it, I am unable to even begin to contribute without the permission of 7 and his team :(

2) people use lots of different environments and we can't possibly document all of them;

I understand, and it makes sense. Best leave it to the community to define and document on different environments.

Hi, I'm @chrishobcroft from the Orchid community. I'm here to try to define and document how to run Orchid on Linux (Ubuntu).

Please can you help me, or would that have too much of a chilling effect on people trying to install on Linux (not-Ubuntu)?

3) we should not be maintaining replicated copies of the installation instructions that have to be kept up to date for every dependency; and

Take a look at how Prysmatic Labs are doing it for their ETH 2.0 client:

https://github.com/prysmaticlabs/prysm/blob/master/prysm.sh

4) I've already gotten explicit complaints from people that we are recommending specific distributions and environments (in particular, someone was quite angry that we are recommending the usage of homebrew, which was a complaint I felt deeply despite having recently "given in": I now am one of those annoying users of homebrew).

Let them get angry. They'll calm down.

And re: Homebrew, I don't know if we can still be friends ;)

[saurik]

You act as if the only way to learn how to install a compiler on Ubuntu is if every single project you use separately re-documents that process, even though it has nothing to do with the project yet is still going to go out of date; and like, your same argument implies that every single project should also provide some rudimentary programming knowledge, or how to use a text editor.

Regardless, while I just fundamentally disagree with your stance here, I will again note that if you actively poke me--summoning me with @saurik--you are going to get my opinion on something... but I purposefully hired someone else to work on this documentation and left decisions on it up to them, and I am pretty sure that they intend to update the documentation to be more inclusive.