Besides, failure to sync ports (both remote and local) with a complaint that /opt/local/var/macports/home does not exist is my local issue?
On Mon, Jul 14, 2025 at 7:09 PM Joshua Root <[email protected]> wrote: > On 14/7/2025 20:40, Chris Jones wrote: > > Yes, but how then do we tell macports to use this when configuring the > > build? The problem is the new path with the random string finds its way > > into all the compilation options which is why cache is sensitive to it. > > e.g. > > > > [4/5838] /opt/local/bin/ccache /usr/bin/clang++ -D__STDC_CONSTANT_MACROS > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/opt/local/var/macports/ > > build/rootHGGlRz/work/build/interpreter/llvm-project/llvm/lib/Demangle - > > I/opt/local/var/macports/build/rootHGGlRz/work/root-6-36-02/interpreter/ > > llvm-project/llvm/lib/Demangle -I/opt/local/var/macports/build/ > > rootHGGlRz/work/build/interpreter/llvm-project/llvm/include -I/opt/ > > local/var/macports/build/rootHGGlRz/work/root-6-36-02/interpreter/llvm- > > project/llvm/include -pipe -I/opt/local/libexec/openssl3/include -Os - > > DNDEBUG -I/opt/local/libexec/openssl3/include -isystem/opt/local/include > > -stdlib=libc++ -isysroot/Library/Developer/CommandLineTools/SDKs/ > > MacOSX.sdk -Wc++11-narrowing -Wsign-compare -Wsometimes-uninitialized - > > Wconditional-uninitialized -Wheader-guard -Warray-bounds -Wcomment - > > Wtautological-compare -Wstrncat-size -Wloop-analysis -Wbool-conversion - > > m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common - > > Qunused-arguments -pthread -stdlib=libc++ -fPIC -fno-semantic- > > interposition -fvisibility-inlines-hidden -Werror=date-time - > > Werror=unguarded-availability-new -w -fdiagnostics-color -O3 -DNDEBUG - > > std=c++17 -arch arm64 -isysroot /Library/Developer/CommandLineTools/ > > SDKs/MacOSX.sdk -mmacosx-version-min=15.0 -fvisibility=hidden - > > fvisibility-inlines-hidden -fno-exceptions -funwind-tables -MD -MT > > interpreter/llvm-project/llvm/lib/Demangle/CMakeFiles/LLVMDemangle.dir/ > > MicrosoftDemangleNodes.cpp.o -MF interpreter/llvm-project/llvm/lib/ > > Demangle/CMakeFiles/LLVMDemangle.dir/MicrosoftDemangleNodes.cpp.o.d -o > > interpreter/llvm-project/llvm/lib/Demangle/CMakeFiles/LLVMDemangle.dir/ > > MicrosoftDemangleNodes.cpp.o -c /opt/local/var/macports/build/ > > rootHGGlRz/work/root-6-36-02/interpreter/llvm-project/llvm/lib/Demangle/ > > MicrosoftDemangleNodes.cpp > > > > All the paths like /opt/local/var/macports/build/rootHGGlRz need to go > > back to something predictable and stable for each port build for the > > ccache option to be useful again. > This means that ccache was already effectively unable to cache results > for (unchanged) files across version updates, right? It looks like the > solution according to the ccache docs is to pass relative paths to the > compiler. I don't know how to make LLVM's build system do that. > > There are some environment variables that might work around the issue: > <https://ccache.dev/manual/latest.html#_configuration_options> > > The trouble with predictable work dir names is that it's basically > impossible for them to be both short and guaranteed to be unique. It > might be possible for them to be somewhat "sticky" (likely to stay the > same for the same port), though that would require some state to survive > a clean, which we don't currently have a way of doing. > > - Josh >
