Moving to a new machine

I'm spending the next couple of days moving to a new machine. It's a 10-core i9 10900K processor with 128 GB of RAM, so builds should go a bit quicker.

Could someone tell me which subdirectories of my LLVM build directory I should copy over so I can then build the system from scratch, but with the same parameters?

Hi Paul,

Maybe I missed something but why do you need to copy directories if you want to build from scratch?
Just use the same CMake arguments you used in the original build.

Best,
Stefanos

Στις Τρί, 23 Φεβ 2021 στις 11:34 μ.μ., ο/η Paul C. Anagnostopoulos via llvm-dev <llvm-dev@lists.llvm.org> έγραψε:

I've edited CMakeCache.txt so many times that I have no idea what to specify on the 'cmake' command line. Should I just guess, run cmake, copy my existing file on top of CMakeCache.txt, and run cmake again?

Hi Paul,

You can run cmake on the new machine, and compare the CMakeCache.txt file with the old one to catch needed variables.

Of course I can. Thanks for the help!

Unless everything is installed in the same location, copying the CMakeCache.txt likely won’t work, as it includes things like paths to compilers in it, if I remember rightly. I’ve used diffs to try to identify which variables I’ve set before, but in practice, I end up just memorizing the three or four variables I tend to change from the defaults.

James

I wrote a short bash script to invoke cmake with all the things I always want. Don’t need to waste valuable neurons on remembering these things.

–paulr

Ah, another good point. Thanks, everyone, for your help with this.

While I've got you, one more question. I've cloned llvm_project on my new machine. I have only one branch that is interesting on my old machine. What is the safest way to bring the files committed on that branch over to the new machine and make a branch with them?

While I've got you, one more question. I've cloned llvm_project on my new
machine. I have only one branch that is interesting on my old machine.
What is the safest way to bring the files committed on that branch over to
the new machine and make a branch with them?

My first thought is to take a diff on the old machine, and apply it on the
new one. This assumes the old branch is "not too different" from main, and
is a set of commits on top of main (and you have been using `git rebase` to
keep it that way). In that case, using `git format-patch` to capture the
commits on the old branch should work well; move the files it creates to
the new system, create a branch there, and use `git am` to apply the patch
files to the new branch.

It's also possible to add the clone on the old system as a remote branch
on the new system, but that seems overly complicated and not worth the
trouble for a one-time move, unless the branch on the old system is not
based on main or has very extensive differences.
--paulr

I am using a shell script that contains the cmake line and that I edit
(&re-run) when I make changes. It also allows me to just delete the
build dir and to start from scratch occasionally.

I think it is useful because as you noticed the CMakeCache.txt does
not indicate which values have been changed from the default, and the
default changes occasionally. For instance, recently the default pass
manager changed to NewPM and I did not notice until I was notified
that the documented workflow does not work anymore and would have to
reset the build directory before I could reproduce it.
Also, sometimes the host environment changes, e.g. after upgrading
the version of the host compiler which requires running cmake again
(cmake will refuse to re-use a build directory if the compiler
changes).

Michael

Of course I'm not done with questions.

When I run CMake, it complains that it cannot find the C, C++, and ASM compilers. I don't recall this problem before. I have Visual Studio installed, but CMake isn't finding it.

If it matters, my build directory is not on the C drive. I'm using Ninja to build.

Are you running these commands from a VS command prompt, or a plain command prompt? I think you have to use the VS command prompt that sets up the environment variables to point to VS compilers, etc.

In addition to David's hint, ensure that you are invoking cmake and
ninja from the right Developer's Command Prompt (e.g. "x64 Native
Tools Command Prompt for VS 2019") or run the batch file that sets up
the paths.(e.g. `call "C:\Program Files (x86)\Microsoft Visual
Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat" amd64`).

Michael

While I've got you, one more question. I've cloned llvm_project on my new machine. I have only one branch that is interesting on my old machine. What is the safest way to bring the files committed on that branch over to the new machine and make a branch with them?

Fork llvm-project on github (or other git hosting site of your
choice), push the branch from your old machine to your fork, and pull
it from your fork onto your new machine. I'm happy to walk you through
this off-list if you want.

Jay.