Some software may break when using the None build type.Some few software projects hardcode -O2 for the Release build type in their CMake files, and thus -DCMAKE_BUILD_TYPE=Release can be safely set in this case if you are sure that -O2 is the optimization level being used. Otherwise, patching the CMake files may be a solution. If upstream defines -O2 for the Release build type, you can use -DCMAKE_BUILD_TYPE=Release (see bellow). There is no standard way of solving this situation and it should be analyzed on a case-by-case basis. What to do if the None build type causes some upstream defined flags to be missed? In this case you may be at the middle of two problematic situations, because if you use the Release build type you may be using the undesired -O3 flag, and if you use the None build type you will miss some required upstream defined flags. In order to determine if you are missing some flags you will need to look at the CMake files, or you can compare the output of make VERBOSE=1 for the None and Release build types. Such software may break or misbehave when compiled without these upstream defined flags if you use the None build type. It is a common practice for many software projects to define some required compiler flags for the Release build type in the CMake files (for example, like setting the CMAKE_C_FLAGS_RELEASE and CMAKE_CXX_FLAGS_RELEASE CMake variables). When using the None build type to fix the -O3 issue, one may fall into another problem. It will cover the case when upstream automatically sets the build type to Release when CMAKE_BUILD_TYPE is omitted, it will not append any flags by default and it is uncommon to see software setting undesired flags for the None build type.īut unfortunately, things are not that simple like only using -DCMAKE_BUILD_TYPE=None to fix this. Generally speaking, using the -DCMAKE_BUILD_TYPE=None option is better than omitting the usage of CMAKE_BUILD_TYPE. Since the default None build type does not append any flags to CFLAGS and CXXFLAGS by default, using the -DCMAKE_BUILD_TYPE=None option can also work. Also be aware of possible references to source files in the resulting package and the corresponding makepkg's WARNING: Package contains reference to $srcdir caused by a missing NDEBUG definition in the None build type. But note that omitting this option is not guaranteed to fix the problem, as many software projects automatically set the build type to Release (or other type) in the CMake files if CMAKE_BUILD_TYPE is not set at command line. The default CMake build type is None and it does not append any flags to CFLAGS and CXXFLAGS by default, so simply omitting the usage of the CMAKE_BUILD_TYPE option can work as it will default to None.
This section will discuss possible solutions and some points that should be observed. Please note that there is no standard solution that can be applied to all cases. Unless you know exactly what you are doing, or if upstream explicitly tells or implies that -O3 is needed, we should avoid using it in our packages.įixing the automatic optimization flag overrideįixing this in a 100% guaranteed way is not a simple question due to CMake flexibility. There is a good reason why the Arch Linux developers choose -O2 as the target optimization level and we should stick with it. It can also break software in some situations. Using -O3 does not guarantee that the software will perform better, and sometimes it can even slow down the program. This is undesired, as it deviates from the Arch Linux targeted optimization level. When using the common Release build type, it automatically appends the -O3 compiler optimization flag, and this overrides the default Arch Linux flag which currently is -O2 (defined in the makepkg configuration file). Some upstream projects even inadvertently include this option in their building instructions, but this produces an undesired behavior.Įach build type causes CMake to automatically append a set of flags to CFLAGS and CXXFLAGS. It is very common to see people running CMake with the -DCMAKE_BUILD_TYPE=Release option.
Being such, some steps should be noted when writing PKGBUILDs for CMake-based software.ĬMake can automatically override the default compiler optimization flag The cmake command usually sets some parameters, checks for the needed dependencies and creates the build files, letting the software ready to be built by other tools like make and ninja.ĭue to its own internal characteristics for generating the build files, sometimes CMake can behave in undesired ways. The typical usage consists of running the cmake command and after that execute the building command. 4.4 Getting all available CMake options.4.3 Removing insecure RPATH references from binaries.
#Cmake linux install#
3 Prefix and library install directories.2.1.2 Fixing the automatic optimization flag override.2.1 CMake can automatically override the default compiler optimization flag.
0 kommentar(er)
