kimwalisch
unity build support
I tried to enable unity build in order to speed up the build of my packages, and primesieve faild with:
PrimeSieve.cpp:36:40: error: conflicting declaration 'const primesieve::Array<{anonymous}::SmallPrime, 8> {anonymous}::smallPrimes'
36 | const primesieve::Array<SmallPrime, 8> smallPrimes
PrimeGenerator.cpp:44:40: note: previous declaration as 'const primesieve::Array<long long unsigned int, 128> {anonymous}::smallPrimes'
44 | const primesieve::Array<uint64_t, 128> smallPrimes =
to enable unty build I configured primesieve with:
cmake -DCMAKE_UNITY_BUILD=ON -DCMAKE_UNITY_BUILD_BATCH_SIZE=32
it works only if I lower the batch size untils these two filles end up in different batches
a possible solution is to eliminate the conflict in the c++ side or mark one of them with SKIP_UNITY_BUILD_INCLUSION property
I did not even know CMake supported unity builds until now.
I have now tried CMake unity builds of these older primesieve versions: 11.1, 11.0, 8.0, 7.9 and 7.0 (which dates back to 2018) and they all failed. So the first good news is that new primesieve-11.2 release from yesterday did not introduce a new bug.
I guess supporting unity builds is not much work, but could you please first explain your primesieve use case? What benefit would primesieve unity build support provide to you?
its just to speed up build, I've been trying that for a bunch of dependencies, for some it can save a lot of CI time
its just to speed up build
What you can now do to speed up your primesieve build (since unity build is not supported yet) is to disable anything that you don't need in the CMake configure step. E.g. by default CMake builds both the static and shared libprimesieve, but you likely only need one of these libraries. Also you might not need the primesieve command-line binary, you can disable it in the CMake configure step.
On my MacBook M2 I can build the shared libprimesieve in parallel in only 1.2 seconds.
cmake .. -DBUILD_SHARED_LIBS=ON -DBUILD_STATIC_LIBS=OFF -DBUILD_PRIMESIEVE=OFF
time cmake --build . --parallel
[ 4%] Building CXX object CMakeFiles/libprimesieve.dir/src/Erat.cpp.o
[ 9%] Building CXX object CMakeFiles/libprimesieve.dir/src/CountPrintPrimes.cpp.o
[ 13%] Building CXX object CMakeFiles/libprimesieve.dir/src/api.cpp.o
[ 18%] Building CXX object CMakeFiles/libprimesieve.dir/src/api-c.cpp.o
[ 27%] Building CXX object CMakeFiles/libprimesieve.dir/src/EratSmall.cpp.o
[ 27%] Building CXX object CMakeFiles/libprimesieve.dir/src/EratMedium.cpp.o
[ 31%] Building CXX object CMakeFiles/libprimesieve.dir/src/CpuInfo.cpp.o
[ 36%] Building CXX object CMakeFiles/libprimesieve.dir/src/IteratorHelper.cpp.o
[ 45%] Building CXX object CMakeFiles/libprimesieve.dir/src/LookupTables.cpp.o
[ 45%] Building CXX object CMakeFiles/libprimesieve.dir/src/iterator-c.cpp.o
[ 54%] Building CXX object CMakeFiles/libprimesieve.dir/src/MemoryPool.cpp.o
[ 54%] Building CXX object CMakeFiles/libprimesieve.dir/src/EratBig.cpp.o
[ 59%] Building CXX object CMakeFiles/libprimesieve.dir/src/iterator.cpp.o
[ 63%] Building CXX object CMakeFiles/libprimesieve.dir/src/PrimeGenerator.cpp.o
[ 68%] Building CXX object CMakeFiles/libprimesieve.dir/src/nthPrime.cpp.o
[ 72%] Building CXX object CMakeFiles/libprimesieve.dir/src/nthPrimeApprox.cpp.o
[ 77%] Building CXX object CMakeFiles/libprimesieve.dir/src/PreSieve.cpp.o
[ 81%] Building CXX object CMakeFiles/libprimesieve.dir/src/ParallelSieve.cpp.o
[ 86%] Building CXX object CMakeFiles/libprimesieve.dir/src/popcount.cpp.o
[ 90%] Building CXX object CMakeFiles/libprimesieve.dir/src/SievingPrimes.cpp.o
[ 95%] Building CXX object CMakeFiles/libprimesieve.dir/src/PrimeSieve.cpp.o
[100%] Linking CXX shared library libprimesieve.dylib
[100%] Built target libprimesieve
cmake --build . --parallel 6.25s user 0.72s system 576% cpu 1.209 total
I did read up on unity builds and after seeing all its drawbacks, I have decided not to support it.
While unity builds are great for the users of a library they are a nightmare for the maintainers (i.e. myself) of the library. E.g. you cannot have global variables with the same name in the entire source tree. This is an issue for primesieve (and primecount) which often uses per .cpp file static constant variables in an anonymous namespace (some of which have identical names). I like this style of coding and don't want to change it.