nvm

nvm copied to clipboard

• Clean up clang related codes and config
• Remove lldb-3.8 package since we don't need, though it's on llvm install instructions.
• The origin codes have a bug about the PATH which makes clang would not be detected/used correctly.
• Remove clang version print.
• Remove useless gcc/g++ related packages and variables.

@ljharb I fixed the conflicts 😄

Hmm - my main concern here is that now we won't be testing gcc-based installation.

Test run speed is less important than testing the maximum amount of use cases.

@ljharb to be honest, I don't think we need to test nodejs as its author will test it, on both gcc and clang, as they write the doc about compilation using gcc/clang, that's their job and we can do nothing, what we should do here is to make sure we pass the correct parameters to "make", am I right?

The thing that needs testing is how nvm compiles it - not that node itself compiles, as it surely will.

While it's a very fair point that simply asserting that we pass the correct parameters to make is a great unit test - and we definitely should add "fast" unit tests for nvm install -s that stubs out nvm_download_artifact and make; that's a wonderful idea - but what that fails to do is integration test nvm install -s on gcc, which is the purpose of the test.

So maybe just separate the "make" part to an individual test for both gcc and clang? Then We don't need to "make" nodejs so many times per CI round.

Yes, I think that would be best - in other words:

1. run at least one nvm install -s test with gcc
2. run at least one nvm install -s test with clang
3. make unit tests that stub things out and test calls to make for gcc
4. make unit tests that stub things out and test calls to make for clang

That should cover all the testing, without adding any slow tests to the build.

@ljharb what's the parameters should be tested in that? If we are not passing some special cases with potential problems, I really doubt if we need to build nodejs in the test.

In numbers 3 and 4? We should test all the permutations we're likely to produce, but because make will be stubbed out, we won't need to build node at all for those (just mock out some of the filesystem stuff that the code expects)

I mean in number 1 and 2, as we won't bump the nodejs version to be tested automatically, a certain build with the same parameters has built successfully should always build successfully with the same parameters, can't we just mock this part by hard code?

Sure, unless the tarballs change retroactively (as they have before).