xmake v2.3.8 released, adding Intel C++/Fortran compiler support

xmake is a lightweight cross-platform build tool based on Lua. It uses xmake.lua to maintain project builds. Compared with makefile/CMakeLists.txt, the configuration syntax is more concise and intuitive, and it is very friendly to novices. You can get started quickly in a short time. Let users focus more on actual project development.

In this new version, we have made full platform support for the Intel series of C++ and Fortran compilers, and improved the Wasm toolchain support added in the previous version. At the same time, we also support the Qt SDK for Wasm.

In addition, we also upgraded luajit to the latest v2.1 version. In terms of cross-platform, xmake has also made great improvements and added support for mips64 architecture.

Introduction of new features

Intel C++ compiler support

On this version, we have made full platform support for the Intel series of C++ compilers, including icl on windows and icc/icpc under linux/macOS.

To enable Intel C ++ compiler, we only need to install on the Intel compiler system, by --toolchain=iccswitching to the corresponding tool chain to parameters.

$ xmake f --toolchain=icc
$ xmake

Intel Fortran compiler support

In the previous version, xmake only supported the gfortran compiler. In this version, we also support the Intel Fortran compiler, which is ifort. We only need to switch to the corresponding ifort tool chain to use it.

$ xmake f --toolchain=ifort
$ xmake

Wasm platform and Qt/Wasm support

The previous version, we added a --toolchain=emcctool chain to support the compilation wasm programs, but only specified tool chain, and not well adjusted extension of the target program, for example, *.jsand *.wasmdocument generation.

The new version, we continue to add a xmake f -p wasmplatform built to enable emcc tool chain, and again based on the configuration around to do a better sound.

By switching to wasm platform, xmake will be generated by default *.jsand corresponding *.wasmand other object files will additionally be loaded js wasm to run the program *.htmlpage.

In addition, we also support Qt SDK for Wasm, for example, we create a Qt QuickApp project.

$ xmake create -t qt.quickapp_static quickapp

Here, we noticed that what we created is a Qt project that requires a static link. Because of the wasm version of the Qt library, we need to force a static link to the program before it can be used normally.

The content of the generated project file xmake.lua is roughly as follows:

add_rules("mode.debug", "mode.release")

includes("qt_add_static_plugins.lua")

target("demo")
    add_rules("qt.quickapp_static")
    add_headerfiles("src/*.h")
    add_files("src/*.cpp")
    add_files("src/qml.qrc")
    add_frameworks("QtQuickControls2", "QtQuickTemplates2")
    qt_add_static_plugins("QtQuick2Plugin", {
    
    linkdirs = "qml/QtQuick.2", links = "qtquick2plugin"})
    qt_add_static_plugins("QtQuick2WindowPlugin", {
    
    linkdirs = "qml/QtQuick/Window.2", links = "windowplugin"})
    qt_add_static_plugins("QtQuickControls2Plugin", {
    
    linkdirs = "qml/QtQuick/Controls.2", links = "qtquickcontrols2plugin"})
    qt_add_static_plugins("QtQuickTemplates2Plugin", {
    
    linkdirs = "qml/QtQuick/Templates.2", links = "qtquicktemplates2plugin"})

The above configuration, in addition to enable us qt.quickapp_staticto compile rules, but also by qt_add_static_pluginsthe configuration of some necessary Qt plugin.

Next, we only need to switch to the wasm platform and make sure that the Qt SDK is set to complete the compilation.

$ xmake f -p wasm [--qt=~/Qt]
$ xmake

After the compilation is completed, xmake will generate demo.html and the corresponding demo.js/demo.wasm program in the build directory. We can open the demo.html page to run the Qt program we compiled. The display effect is as follows:

For a more detailed description of Qt/Wasm, see: Issue #956

Added Math/Float-point compilation optimization settings

We've added a set_fpmodels()setting interface for setting the floating-point compiler mode, the calculation of the mathematical compiler optimization related abstract settings, provide: fast, strict, except, precise and so are several common level, and some can be set at the same time, some are If there is a conflict, the last setting will take effect.

For the description of these levels, you can refer to the Microsoft document: Specify floating-point behavior

Of course, for other compilers such as gcc/icc, xmake will map to different compilation flags.

set_fpmodels("fast")
set_fpmodels("strict")
set_fpmodels("fast", "except")
set_fpmodels("precise") -- default

For details on this, see: Issue #981

OpenMP support

In order to enable a more abstract simple openmp characteristics, we can add the c.openmpand c++.openmpto set these two rules, in addition linux, on macOS we need additional libomp library for the job, and therefore can be add_requires("libomp")quickly referenced and integrated to.

add_requires("libomp", {
    
    optional = true})
target("loop")
    set_kind("binary")
    add_files("src/*.cpp")
    add_rules("c++.openmp")
    add_packages("libomp")

If it is c code, it needs to be enabled add_rules("c.openmp"). If it is c/c++ mixed compilation, then these two rules must be set.

c11/c17 support

The new version, xmake to set_languageshave made improvements, adding new c11 / c17 settings, while the latest version msvc provided /std:c11and /std:c17also made fit and support.

We only need simple settings:

set_languages("c17")

You can enable the c17 standard to compile, even if the lower version of msvc and other compilers do not support it, xmake will automatically ignore the settings.

Better Mingw support

On improving this, involving several aspects, the first is to improve the automatic detection of Mingw SDK root directory under Windows, in most cases, we do not need additional configuration --mingw=parameters explicitly specified path can be automatically detected.

For details on this, see: Issue #977

In addition, in addition to Msys2/Mingw as well as macOS, linux/Mingw, we additionally support the llvm-mingw SDK in the new version , so that we can use mingw to compile programs of the arm/arm64 architecture.

$ xmake f -p mingw -a arm64
$ xmake

In addition, in the automatic compilation and integration of remote dependency packages, there are now third-party libraries with cmakelists. Even on the mingw platform, xmake can be automatically compiled and integrated for direct use, which is very fast and convenient.

Recently, in the official C/C++ package repository of xmake-repo , we have also added a lot of new libraries that support the mingw platform, which can be used directly.

Better cross-platform operation

We have added support for mips64-based Linux system operation, and improved the stability of xmake under arm/arm64. By incorporating the latest luajit v2.1, we have solved many problems left by luajit, such as the bad of lightuserdata under arm64. Pointer and other issues.

Added macOS Sierra for arm64 support

xmake also adapts to the latest Xcode-beta, and adds macOs for arm64 target program compilation support. You only need to switch to the arm64 architecture to compile.

$ xmake f -a arm64 [--xcode=Applications/Xcode-beta.app/]
$ xmake

Of course, the premise is to run under macOS and use the latest Xcode-beta version that supports the Developer Transition Kit (DTK).

The official warehouse contains more C/C++ libraries

In xmake -repo , the official C/C++ repository of xmake , we have recently added dozens of commonly used C/C++ libraries, and we have also included all the libraries of the libx11 series.

Although the warehouse package maintenance workload is huge, the current development trend is also becoming more and more active. We have received more and more users' contributions to the warehouse package and improved maintenance.

And, now our official warehouse can be quickly integrated: linux, macOS, windows, mingw, bsd, msys, iphoneos, android and other eight common platform libraries, to achieve true cross-platform C/C++ remote dependency library integration and use support.

Currently we have included a list of some packages and supporting platforms, you can check here: PKGLIST.md

We have been working hard to solve the problems of the clutter of the C/C++ library ecology and the cumbersome integration and use, and provide fast and consistent automatic integration and compilation solutions. xmake not only supports the integration of third-party official warehouse packages such as vcpkg/conan/clib/homebrew, but also We are working hard to improve our self-built official warehouse to achieve a better integrated experience.

E.g:

add_requires("tbox >1.6.1", "libuv master", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8")
add_requires("conan::openssl/1.1.1g", {
    
    alias = "openssl", optional = true, debug = true})
target("test")
    set_kind("binary")
    add_files("src/*.c")
    add_packages("tbox", "libuv", "vcpkg::ffmpeg", "brew::pcre2/libpcre2-8", "openssl")

With vcpkg::, brew::and conan::packages such as namespaces, will automatically switch to the corresponding package repository to download third-party integration, while default tbox >1.6.1and other libraries will use the default package xmake-repo official repository provided.

The usage and integration methods are exactly the same, xmake will automatically download, compile, integrate and link.

For more detailed instructions on the dependency integration of remote packages, we can look at the relevant documentation: remote dependency library integration and use

At the same time, we also welcome more people to participate to help improve the construction of the C/C++ library ecology and provide a concise and consistent library experience. I believe that C/C++ package management and library ecology are no worse than Rust/Go.

More distribution installation support

In the new version, we submitted xmake to the Ubuntu PPA source, so in addition to the existing script installation method, we can also quickly install xmake through apt.

sudo add-apt-repository ppa:xmake-io/xmake
sudo apt update
sudo apt install xmake

At the same time, we also submitted the package to the Copr package management repository, so that we can also quickly install xmake through dnf in Fedora, RHEL, OpenSUSE, CentOS and other distributions.

sudo dnf copr enable waruqi/xmake
sudo dnf install xmake

Introductory course

Recently, we have also launched the official xmake introductory course. Xmake will take you to easily build C/C++ projects to quickly learn the use of xmake by doing experiments while learning.

update content

New features

  • #955 : Add Zig empty project template
  • #956 : Add Wasm compilation platform and support Qt/Wasm SDK
  • Upgrade luajit to the latest branch version of v2.1, and support running xmake on mips64
  • #972 : Added depend.on_changed()to simplify handling of dependent files
  • #981 : Add set_fpmodels()de-abstraction setting math/float-point compilation optimization mode
  • #980 : Add full platform support for Intel C/C++ and Fortran compilers
  • #986 : Add c11/ c17support msvc compiler above 16.8
  • #979 : Add cross-platform abstract configuration for OpenMP.add_rules("c++.openmp")

Improve

  • #958 : Improve mingw platform, add support for llvm-mingw tool chain, and support for arm64/arm architecture
  • Increasing add_requires("zlib~xxx")mode makes it possible to support both packets with a plurality of mounting the same configuration as the presence of an independent package
  • #977 : Improve the detection of find_mingw on windows
  • #978 : Improve the flags order of the tool chain
  • Improve XCode tool chain, support macOS/arm64

Bugs fixed

  • #951 : Fix emcc (WebAssembly) toolchain support on windows
  • #992 : Fix the problem that the file lock occasionally fails to open

https://tboox.org/cn/2020/10/17/xmake-update-v2.3.8/

Guess you like

Origin blog.csdn.net/waruqi/article/details/109141608