Xmake v2.8.1 is released, a lot of details and features have been improved

Xmake  is a lightweight cross-platform build tool based on Lua.

It's very lightweight and doesn't have any dependencies because it has a built-in Lua runtime.

It uses xmake.lua to maintain project construction. Compared with makefile/CMakeLists.txt, the configuration syntax is more concise and intuitive. It is very friendly to novices. It can be quickly started in a short time, allowing users to focus more on actual project development superior.

We can use it to directly compile projects like Make/Ninja, or generate project files like CMake/Meson, and it also has a built-in package management system to help users solve the problem of integrated use of C/C++ dependent libraries.

At present, Xmake is mainly used to build C/C++ projects, but it also supports the construction of other native languages. It can realize mixed compilation with C/C++, and the compilation speed is also very fast, which can be equal to that of Ninja.

Xmake = Build backend + Project Generator + Package Manager + [Remote|Distributed] Build + Cache

Although not very accurate, we can still understand Xmake in the following way:

Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache

Introduction of new features

Improvements to Windows long path issues

The long path limitation of windows has always been a big problem. Projects with too deep nesting levels may fail when reading and writing files, which will affect the usability and experience of xmake.

Although xmake has provided various measures to avoid this problem, it is still subject to some restrictions occasionally. In this version, we have improved the installer and provided an installation option that allows users to selectively enable long path support.

This requires admin privileges as it needs to write to the registry.

WriteRegDWORD ${HKLM} "SYSTEM\CurrentControlSet\Control\FileSystem" "LongPathsEnabled" 1

Users can decide whether to enable it or not.

Thanks to @A2va for his contribution.

zypper package manager support

Added support for OpenSUSE's zypper package manager, which can automatically download and install directly through zypper, and integrate the packages it provides.

Thanks to @iphelf for his contribution.

add_requires("zypper::libsfml2 2.5")

Improve msbuild package installation

Some third-party packages are not maintained by cmake and only provide vcproj project files. If we make it into a package, we need to use modules to compile and install it. tools.msbuild 

But if the vs version of vcproj is very old, you need to upgrade it, otherwise the compilation will fail.

Therefore, we have improved the tools.msbuild module to provide the function of automatically upgrading vcproj, and only need to specify the vcproj/sln file that needs to be upgraded.

package("test")
    on_install(function (package)
        import("package.tools.msbuild").build(package, configs, {upgrade={"wolfssl64.sln", "wolfssl.vcxproj"}})
    end)

Improve protobuf to support grpc

We have improved the support for protobuf and can support grpc_cpp_plugin at the same time.

add_rules("mode.debug", "mode.release")
add_requires("protobuf-cpp")
add_requires("grpc", {system = false})

target("test")
    set_kind("binary")
    set_languages("c++17")
    add_packages("protobuf-cpp")
    add_packages("grpc")
    add_rules("protobuf.cpp")
    add_files("src/*.cpp")
    add_files("src/test.proto", {proto_rootdir = "src", proto_grpc_cpp_plugin = true})
    add_files("src/subdir/test2.proto", {proto_rootdir = "src"})

For a complete example see: protobuf_grpc_cpp_plugin

add_links support library path

Usually add_links needs to be used in conjunction with add_linkdirs to allow the linker to find the library files in the specified directory.

But sometimes the configuration is wrong, or the library has the same name under different paths, it is easy to find the wrong library file. Now add_links can support directly setting the library file path to avoid implicit search.

Can also be used to explicitly link against the so/a library.

The following writing methods are supported:

add_links("foo")
add_links("libfoo.a")
add_links("libfoo.so")
add_links("/tmp/libfoo.a")
add_links("/tmp/libfoo.so")
add_links("foo.lib")

Objc/Objc++ header file precompilation support

In the previous version, if we precompile with the c++ header file, it will affect the objc code at the same time. set_pcxxheader 

Therefore, if the C++/ObjC++ code is mixed and compiled, and the precompiled header is used, it will encounter compilation problems.

Objective-C was disabled in PCH file but is currently enabled

This is because the compilation of the precompiled header also needs to specify the language , and the pch files cannot be mixed. -x c++-header -x objective-c++-header

Therefore, we have added an interface to set objc/objc++ precompiled header files separately, so as not to conflict with C/C++ precompiled headers. set_pmheader  set_pmxxheader 

But the usage is exactly the same.

target("test")
    set_pmxxheader("header.h")

For a complete example see: Objc Precompiled Header Example

Improved Conan 2.0 support

In the last version, we initially supported Conan 2.0, but we still encountered some detailed problems. We have continued to make improvements in this version, such as improving the vs_runtime setting.

update lua runtime

Recently, Lua has released version 5.4.6, and we have also upgraded the built-in Lua runtime in xmake to keep pace with the upstream.

update log

new features

  • #3821 : windows installer add long path support option
  • #3828 : Add zypper package manager support
  • #3871 : Improve tools.msbuild to support automatic upgrade of vsproj
  • #3148 : Improve protobuf support grpc
  • #3889 : add_links supports library path addition
  • #3912 : Add set_pmxxheader to support objc precompiled headers
  • add_links support library file path

Improve

  • #3752 : Improve fetching of os.getenvs on windows
  • #3371 : Improve tools.cmake to support using ninja to build wasm packages
  • #3777 : Improve finding packages from pkg-config
  • #3815 : Improve tools.xmake support to pass toolchain for windows platform
  • #3857 : Improve generating compile_commands.json
  • #3892 : Improve package search, support finding package from description
  • #3916 : Improve building swift programs, support inter-module symbol calls
  • Update lua runtime to 5.4.6

Bug fixes

  • #3755 : Fix find_tool to find programs from xmake/packages
  • #3787 : Fix using packages from conan 2.x
  • #3839 : Fix vs_runtime setting for conan 2.x package

Guess you like

Origin www.oschina.net/news/248889/xmake-2-8-1-released