I have recorded that it took 50 minutes for an initial compilation of the OpenWrt firmware image, assuming all the necessary packages have been installed via sudo apt-get install. My BuildRoot Root Dir is openwrt.

Subsequently, I found that if I rename the directory above the openwrt folder, with a minor change in a file say wifi.lua the next make (in openwrt folder) takes 21 minutes to compile successfully.

However, if I don't rename the directory above the openwrt folder, with a similar minor change in the same file, the next make V=99 takes only 3 minutes to compile successfully.

When I now rename the directory above and do the same as above again, the make takes 21 minutes to compile successfully. With make V=99, I can see that there were many more compilation steps taken compared to the case where I did not rename the top directory.

I can see that the Makefile compilation is much faster if I do not rename the top directory.

This brings me to the related question:
In Linux, will renaming or moving a directory change the times of the files in subdirectories?

I know that the Makefile does not build a target again if the modification time of the target is more recent than all its dependencies.

2 Answers
2

No, it doesn't change the timestamps of contained files and directories, only on the directory itself. However, if the Makefile contains targets or dependencies that use absolute paths or even just $(src_dir) it will remake them, b/c it's a different/new target. See the GNU make documentation for conventions and advice on "standard" targets and variables.

However, Makefiles don't compile and there is no such thing as the original Linux Makefile. Creating/maintaining an environment like BuildRoot is very complex and the maintainers probably focus on getting it to build correctly before efficiently. If a simple patch, like adding a symlink helps to speed up the process, maybe you should send it as a suggestion for improvement upstream.

-j [jobs], --jobs[=jobs]Specifies the number of jobs (commands) to run simultaneously. If there is more than one -j option, the last one is effective. If the -j option is given without an argument, make will not limit the number of jobs that can run simultaneously.