Added Multiple Core build support option

[erfanmola]

Added an option to chose multi core build by using clang's -j parameter

[levlam]

This ability is intentionally omitted, because building in multiple threads will fail for most users, which don't have enough RAM. It also requires a new enough CMake, which supports the -j option.

[erfanmola]

This ability is intentionally omitted, because building in multiple threads will fail for most users, which don't have enough RAM. It also requires a new enough CMake, which supports the -j option.

Fair enough, but since the option is optional like "Enable Link Time Optimization", might be worth a notice that it has an specific cmake version requirement and if not sufficent RAM or in general may lead to compile errors, but otherwise it would multiply compilation speed

If this would be acceptable, I could update and PR

[levlam]

The purpose of the build instructions generator is to provide build instructions, which will definitely work. In the very common case there is not enough RAM even for building TDLib in 1 thread, so the ability to specify any bigger value will be harmful. Adding options, which can lead to a failed build, will help noone. People will be tired by searching for a working option combination. Even presence of LTO as an option for macOS and Ubuntu distros is harmful, because LTO doesn't work too often.

Moreover, TDLib needs to be rebuild very rarely, usually once a month. There are no reasons to speed up this for most use cases, and C++ developers don't need the build instructions generator to build a CMake project in parallel.

[Patovic23]

Me salvó y esto es un homenaje

[zadorozhko]

@levlam Just curious about coding style that can cause fail on ENOMEM when building in single thread. Linux kernel, gcc or glibc have much more source code than tg-bot-api, and perfectly can be compiled with -j8 on 8GB system.
Also it's unclear about "It also requires a new enough CMake, which supports the -j option" The -j option, used for parallel builds, is not a CMake option but rather an option for build tools like Make or Ninja, which are invoked by CMake. The ability to use parallel compilation with -j has been available in tools like Make for a long time.
I will definitely test this PR on common macbook, because my 64-core 256GB build server will eat this anyway.

[levlam]

@zadorozhko

Just curious about coding style that can cause fail on ENOMEM when building in single thread. Linux kernel, gcc or glibc have much more source code than tg-bot-api, and perfectly can be compiled with -j8 on 8GB system.

Those are C projects and not C++ projects hence your comparison is absolutely irrelevant.
The coding style used in this project tends to minimize the RAM requirements and total build time opposite to many other C++ libraries which are "header-only". For example, this project uses custom implementation of std::unique_ptr, which reduces build-time RAM requirements for each instance of the class dozens of times.

Also it's unclear about "It also requires a new enough CMake, which supports the -j option" The -j option, used for parallel builds, is not a CMake option but rather an option for build tools like Make or Ninja, which are invoked by CMake.

You are wrong. The tools are invoked by CMake and it must know how to ask the tools to use parallel building. The -j option was added in CMake 3.12 and isn't available in the older CMake versions: https://cmake.org/cmake/help/v3.11/manual/cmake.1.html. Passing -j directly to the native build tool is not a portable approach by definition. But if you know that cmake used make as build tool then you are free to run make -j. This was also covered by "C++ developers don't need the build instructions generator to build a CMake project in parallel".

[zadorozhko]

@levlam Okay man, let's run a test. Pre-req's: Apple Air M1, 8Gb. Apple clang version 17.0.0 (clang-1700.0.13.3)
Target: arm64-apple-darwin24.5.0
We have -- cmake opt to pass -j downstairs, so cmake --build . --target install -- -j8
I see all 8 cpu's busy at 100, ram usage is around average, swap also ok.
Yes, it took some time, but everything compiled ok, I see no problems.
Btw, you can use -- -j option to cmake < 3.12, works perfect.

[levlam]

@zadorozhko

Btw, you can use -- -j option to cmake < 3.12, works perfect.

No, it doesn't work for most build tools. Passing -j directly to the native build tool is not a portable approach by definition. And if you know that cmake used make as build tool then you are free to run make -j8 install instead of the portable cmake command.

[zadorozhko]

@levlam Man, I don't understand what the case you're complaining about. I can prove -j8 is working on Air M1 out of box, it is tested, you're say it doesn't work for most build tools. Can you provide any example where it is not working, I have a lot of VPS to test in different environments.

[levlam]

@zadorozhko See https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#id9 for the list of generators supported by CMake. Passing any argument after -- is not a portable approach by definition and will not work for most generators.

I have a lot of VPS to test in different environments.

You also seems to see no difference between "something is correct" and "something works for me".

[zadorozhko]

@levlam Let's close this, we're speaking in different languages. My approach is to use things that can speed up development as much as possible. This one is not new and WIDELY used for long years - it was introduced in 1999, in the last century. I don't sure there is still any working computers from that time outside archaeological museums. And I'm pretty sure no one of these 80286 or 68000 can compile this api with or without -j option. Backward compatibility is quite good thing, but one day it is time to take your favorite punched tape to the dump.

[enganese]

^legit, well done, approved