What's the proper way to re-build?

[stefanct]

Since the top makefile uses the stamps to assess progress instead of leaving this to the sub-makes, it is not aware of changes in the repos during development or when updating. I used to remove the respective stamp files manually but I am not sure if that's the most appropriate way and would like to see this documented as too (I can send a PR once I fully understand the issue).

How to re-build the whole toolchain or individual parts after the toolchain was built (e.g., when pulling new changes)?

[TommyMurphyTM1234]

For a clean full build I normally do the following which seems to work (installed-tools is the directory specified at configuration time via --prefix)

rm -rf installed-tools
make distclean
make

I'm not sure if/how an incremental/partial rebuild can be done.

[cmuellner]

Yes, removing the stamp files is a good way to keep incremental build durations short.
I also use ccache to make clean builds much faster.

I'm not sure an automatic logic that fits all use-cases can exist. E.g. Binutils changes sometimes require a rebuild of following toolchain components, but I don't think this can be detected automatically. So a proper solution would be to do only clean builds unless you know better, in which case you would remove the stamp files of those components that should be rebuilt.

[kito-cheng]

I also using the removing stamp trick now.

I've some experiences on building build system to handle this automatically, but no much magic here - scan latest modify time in the source tree, rebuild if latest modify time is older than the stamp file, and also add build flag to notify the build system should rebuild C library (e.g newlib or glibc), however it's not written in Makefile...and I can no longer use that for many years...:P

[TommyMurphyTM1234]

Anybody know the difference between removing the stamps files and doing make distclean so?

[cmuellner]

make distclean will remove all build directories and stamp files (rm -rf build-* stamps). But let's say, we added a feature to glibc, then we don't need to remove anything related to Binutils. So make distclean is not wrong, but it would result in a longer build/test cycle.

[TommyMurphyTM1234]

Thanks Christoph.

So make distclean is not wrong, but it would result in a longer build/test cycle.

Yes, but earlier it was stated:

So a proper solution would be to do only clean builds unless you know better

So, that suggests to me that make distclean is precisely what one should be using in the absence of dependable sub-project dependency checking in the top-level riscv-gnu-toolchain Makefile?

[cmuellner]

Yes, rm -rf $INST_DIR ; make distclean a 100% reliable way to ensure a clean build.
Others might use rm -rf "$INST_DIR"/* ; git clean -dffx to achieve the same.

It might be worth mentioning that these steps won't help in case of version bumps of the submodules. I typically use rm -rf * ; git checkout * in this case. People with a better relationship with git submodules might use a less drastic command.

[TommyMurphyTM1234]

Closing this since different ways to do a clean rebuild have been outlined and, as far as I can see, no change is needed to the riscv-gnu-toolchain build files.

[stefanct]

Well, not the build files but maybe the documentation aka readme? The gist of this threads seems to be:

We recommend to do clean builds, e.g., by executing

rm -r $RISCV ; git clean -fXd

before (re)running configure. (NB: no / trailing the rm command(!) and X instead of x in the git clean command. Both reduces the risk of involuntary data loss).

Partial rebuilds can be done by deleting the respective files in stamps/ and rerunning make but is not recommended if the sources have changed due to possible interdependencies of the steps.

[TommyMurphyTM1234]

Well, not the build files but maybe the documentation aka readme? The gist of this threads seems to be:

We recommend to do clean builds, e.g., by executing

rm -r $RISCV ; git clean -fXd

before (re)running configure. (NB: no / trailing the rm command(!) and X instead of x in the git clean command. Both reduces the risk of involuntary data loss).

Partial rebuilds can be done by deleting the respective files in stamps/ and rerunning make but is not recommended if the sources have changed due to possible interdependencies of the steps.

Feel free to submit a PR for the changes that you consider appropriate.

[TommyMurphyTM1234]

Yes, removing the stamp files is a good way to keep incremental build durations short. I also use ccache to make clean builds much faster.

Hi @timsifive - can I ask how exactly you do this? Is it via something like make "CC=ccache gcc" newlib or something else?
For example do you also have to ensure that ccache is used for native g++ and maybe also for the RISC-V gcc/g++ etc.?

[TommyMurphyTM1234]

Yes, removing the stamp files is a good way to keep incremental build durations short. I also use ccache to make clean builds much faster.

Hi @timsifive - can I ask how exactly you do this? Is it via something like make "CC=ccache gcc" newlib or something else? For example do you also have to ensure that ccache is used for native g++ and maybe also for the RISC-V gcc/g++ etc.?

Actually, this seems to work for me - just in case it helps anybody else...

sudo apt install ccache

cd /usr/lib/ccache
sudo ln -s ../../bin/ccache riscv32-unknown-elf-gcc
sudo ln -s ../../bin/ccache riscv32-unknown-elf-g++
sudo ln -s ../../bin/ccache riscv64-unknown-elf-gcc
sudo ln -s ../../bin/ccache riscv64-unknown-elf-g++
sudo ln -s ../../bin/ccache riscv32-unknown-linux-gnu-gcc
sudo ln -s ../../bin/ccache riscv32-unknown-linux-gnu-g++
sudo ln -s ../../bin/ccache riscv64-unknown-linux-gnu-gcc
sudo ln -s ../../bin/ccache riscv64-unknown-linux-gnu-g++
sudo ln -s ../../bin/ccache riscv64-unknown-linux-musl-gcc
sudo ln -s ../../bin/ccache riscv64-unknown-linux-musl-g++

ls -l
total 0
lrwxrwxrwx 1 root root 16 May 28 13:18 c++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 c89-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 c99-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 cc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 g++-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 gcc-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:47 riscv32-unknown-elf-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:47 riscv32-unknown-elf-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:55 riscv32-unknown-linux-gnu-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:55 riscv32-unknown-linux-gnu-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 23:26 riscv64-unknown-elf-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 23:26 riscv64-unknown-elf-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:55 riscv64-unknown-linux-gnu-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:55 riscv64-unknown-linux-gnu-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:55 riscv64-unknown-linux-musl-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 29 08:55 riscv64-unknown-linux-musl-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 x86_64-linux-gnu-g++ -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 x86_64-linux-gnu-g++-9 -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 x86_64-linux-gnu-gcc -> ../../bin/ccache
lrwxrwxrwx 1 root root 16 May 28 13:18 x86_64-linux-gnu-gcc-9 -> ../../bin/ccache

export PATH=/usr/lib/ccache:$PATH

cd ~/Downloads
git clone --recursive https://github.com/riscv-collab/riscv-gnu-toolchain
cd riscv-gnu-toolchain
./configure --prefix=`pwd`/installed-tools

date > make-newlib-1.log && make newlib 2>&1 | tee -a make-newlib-1.log && date >> make-newlib-1.log
make distclean && rm -rf installed-tools
date > make-newlib-2.log && make newlib 2>&1 | tee -a make-newlib-2.log && date >> make-newlib-2.log

head -1 make-newlib-1.log && tail -1 make-newlib-1.log 
Mon 29 May 2023 09:02:51 IST
Mon 29 May 2023 12:46:10 IST

head -1 make-newlib-2.log && tail -1 make-newlib-2.log 
Mon 29 May 2023 12:50:20 IST
Mon 29 May 2023 13:20:11 IST

So a clean build from scratch with an empty ccache cache took c. 3 hours 45 minutes while a clean build with a populated ccache cache took 30 mins!

I was also meaning to try distcc, just out of curiosity, but haven't got around to it yet.

P.S. a clean build (as before, with all git submodules already fetched) without using ccache at all takes c. 3 and a half hours so, when using ccache the initial build that populates the cache adds about 15 mins.

Tue 30 May 2023 08:56:27 IST
Tue 30 May 2023 12:22:15 IST

[TommyMurphyTM1234]

Closing this since the original and follow-up questions have been addressed and the close issue will remain as a useful reference point going forward.