Bug 256783 - Mk/Uses/cmake.mk: Some cmake ports builds twice
Summary: Mk/Uses/cmake.mk: Some cmake ports builds twice
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-kde (Team)
Keywords: needs-qa, performance
Depends on:
Reported: 2021-06-22 21:53 UTC by Ivan Rozhuk
Modified: 2021-07-29 10:52 UTC (History)
8 users (show)

See Also:
koobs: maintainer-feedback? (kde)
koobs: merge-quarterly?

build log (87.81 KB, text/plain)
2021-06-28 15:29 UTC, Ivan Rozhuk
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Rozhuk 2021-06-22 21:53:47 UTC
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
Comment 1 Ivan Rozhuk 2021-06-22 22:01:56 UTC
Probably add_subdirectory() in CMakeLists.txt + USES=cmake:noninja affect this
Comment 2 Adriaan de Groot freebsd_committer 2021-06-27 22:44:43 UTC
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.
Comment 3 Ivan Rozhuk 2021-06-28 15:29:01 UTC
Created attachment 226090 [details]
build log
Comment 4 Adriaan de Groot freebsd_committer 2021-06-30 11:48:44 UTC
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.
Comment 5 Ivan Rozhuk 2021-07-29 10:52:45 UTC
Looks like fixed, after one of cmake update, I suppose.