devel/doxygen comms/svxlink devel/cpp-hocon sysutils/facter multimedia/kodi-addon-pvr.hts (but multimedia/kodi-addon-pvr.iptvsimple is OK) Second build start on make stage. ... [100%] Built target ModuleEchoLink /usr/local/bin/cmake -E cmake_progress_start /tmp/ports/usr/ports/comms/svxlink/work/.build/CMakeFiles 0 ===> Staging for svxlink-19.09.1_2 ===> Generating temporary packing list /usr/local/bin/cmake -S/tmp/ports/usr/ports/comms/svxlink/work/svxlink-19.09.1/src -B/tmp/ports/usr/ports/comms/svxlink/work/.build --check-build-system CMakeFiles/Makefile.cmake 0 /usr/local/bin/cmake -E cmake_progress_start /tmp/ports/usr/ports/comms/svxlink/work/.build/CMakeFiles /tmp/ports/usr/ports/comms/svxlink/work/.build//CMakeFiles/progress.marks /usr/bin/make -f CMakeFiles/Makefile2 all /usr/bin/make -f async/core/CMakeFiles/asynccore.dir/build.make async/core/CMakeFiles/asynccore.dir/depend cd /tmp/ports/usr/ports/comms/svxlink/work/.build && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/ports/usr/ports/comms/svxlink/work/svxlink-19.09.1/src /tmp/ports/usr/ports/comms/svxlink/work/svxlink-19.09.1/src/async/core /tmp/ports/usr/ports/comms/svxlink/work/.build /tmp/ports/usr/ports/comms/svxlink/work/.build/async/core /tmp/ports/usr/ports/comms/svxlink/work/.build/async/core/CMakeFiles/asynccore.dir/DependInfo.cmake --color= Consolidate compiler generated dependencies of target asynccore /usr/bin/make -f async/core/CMakeFiles/asynccore.dir/build.make async/core/CMakeFiles/asynccore.dir/build [ 1%] Building CXX object async/core/CMakeFiles/asynccore.dir/AsyncApplication.cpp.o ...
Probably add_subdirectory() in CMakeLists.txt + USES=cmake:noninja affect this
To some extent this is expected: CMake (re-)links executables while installing. You can see that with these four files (CMakeLists.txt, main.c, tu.c, tv.c): ``` [adridg@beastie /tmp]$ cat CMakeLists.txt cmake_minimum_required(VERSION 3.16 FATAL_ERROR) project(derp LANGUAGES C) add_executable(derp1 tu.c main.c) add_executable(derp2 tv.c main.c) install(TARGETS derp1 derp2 DESTINATION /tmp) [adridg@beastie /tmp]$ cat main.c extern int x; int main(int argc, char** argv) { return x * argc; } [adridg@beastie /tmp]$ cat tu.c int x = 0; [adridg@beastie /tmp]$ cat tv.c int x = 1; ``` With `make`, the objects are built, and the executables linked: ``` [adridg@beastie /tmp]$ make [ 16%] Building C object CMakeFiles/derp1.dir/tu.c.o [ 33%] Building C object CMakeFiles/derp1.dir/main.c.o [ 50%] Linking C executable derp1 [ 50%] Built target derp1 [ 66%] Building C object CMakeFiles/derp2.dir/tv.c.o [ 83%] Building C object CMakeFiles/derp2.dir/main.c.o [100%] Linking C executable derp2 [100%] Built target derp2 ``` And then `make install` (which is what staging does) does some re-compilation and re-linking: ``` [adridg@beastie /tmp]$ make install Consolidate compiler generated dependencies of target derp1 [ 50%] Built target derp1 Consolidate compiler generated dependencies of target derp2 [100%] Built target derp2 Install the project... -- Install configuration: "" ``` I built comms/svxlink and devel/cpp-hocon in poudriere just now, and while there is the expected consolidation / re-linking, I don't see the kind of rebuild you show in your log. I suspect time drift, frankly.
Created attachment 226090 [details] build log
It's not that I don't believe you, it's that I have no idea how to reproduce this -- or even why it's an issue, really. Your latest log shows hts being built, and then at stage-time five (if I counted right) C files are re-compiled. Not even all of them (here in hts, just the `kissnet/` subdirectory). Locally, nothing is rebuilt; I've tried with MAKE_JOBS_UNSAFE, and without. In poudriere, and in the host, as root and as user. I'd suggest building this up to pre-stage and then executing the steps in stage by hand, to figure out what's going on and why make is rebuilding things. The relevant steps are (here from my build, which has slightly different paths): ``` /usr/bin/make -f lib/kissnet/CMakeFiles/hts.dir/build.make lib/kissnet/CMakeFiles/hts.dir/depend cd /tmp/port/work/.build && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /tmp/port/work/pvr.hts-8.3.0-Matrix /tmp/port/work/pvr.hts-8.3.0-Matrix/lib/libhts /tmp/port/work/.build /tmp/port/work/.build/lib/kissnet /tmp/port/work/.build/lib/kissnet/CMakeFiles/hts.dir/DependInfo.cmake --color= Consolidate compiler generated dependencies of target hts /usr/bin/make -f lib/kissnet/CMakeFiles/hts.dir/build.make lib/kissnet/CMakeFiles/hts.dir/build ``` If you can trace those two `make` invocations to see exactly what is being rebuilt and why, **then** there's a chance to track this down.
Looks like fixed, after one of cmake update, I suppose.