preface

After more than four months, Xmake has released a new version, V2.2.2, with a heavyweight feature: natively supported remote dependency package management.

In fact, I have been writing about this feature for nearly a year. For the development progress and history of this feature, please refer to the relevant issues: #69.

  • Program source code
  • The official documentation

The current implementation looks like this, with exactly the same semantic version depending on the description:

Fully consistent cross-platform build behavior, one-click Xmake compilation:

Complete project description:

add_requires("Tbox 1.6. *"."Libpng ~ 1.16"."zlib")



target("test")

    set_kind("binary")

    add_files("src/*.c") 

    add_packages("tbox"."libpng"."zlib")

Copy the code

Let me give you a little background on why I made this feature:

When we write C/C++ programs, the use of third-party dependency libraries has always been a big problem, because each dependency library construction system is different, code platform support is different, resulting in no convenient package management support like other high-level languages.

Although there are now homebrew, VCPKG and other package management tools to solve this problem, but there are some limitations, such as:

  1. Homebrew does not support iphoneos, android, or Windows platforms
  2. VCPKG does not support semantic version selection and multiple version management
  3. In addition, they do not support project management and construction

For the existing cross-platform building tools, there is a lack of built-in package management support. For example, Cmake only provides find_package to find system packages. Although it can be used with third-party package management such as VCPKG, I personally think it is not very convenient. This will cause other users of the project to have to install VCPKG or dependencies on the system at compile time, which is easier for PC platforms but more difficult for iphoneos, android, etc.

The philosophy of Xmake is: true consistent maintenance, true one-click compilation

  • Consistent build behavior: Whether or not your project has library dependencies, tool dependencies, only one needs to be implementedxmakeCommand, you can compile through.
  • Consistency of project maintenance: Whether your project is running on Windows, Linux, iPhone, or Android, all you need is a xmake. Lua maintenance project.

Cmake also needs to generate additional third-party IDE project files. Even if cmakelist.txt is the same, it is impossible to guarantee the same construction and maintenance experience for users. After all, it is also limited by vc/make tools.

Currently supported features

  • Semantic versioning support, for example: “> = 1.1.0 < 1.2”, “1.6”, “1.2 x”, “1. *”
  • Provide official package warehouse, self-built private warehouse, project built-in warehouse and other warehouse management support
  • Cross-platform package compilation and integration support (packages of different platforms and architectures can be installed at the same time for quick switching)
  • Debug depends on package support for source code debugging

Depend on the package handling mechanism

Here we briefly introduce the whole dependency package processing mechanism:

  1. Check whether the specified package exists under the current system directory and third-party package management first. If there is a matching package, then there is no need to download and install it (of course, you can also set not to use the system package).
  2. Retrieve the package that matches the corresponding version, then download, compile, and install it (note: install it in a specific Xmake directory without interfering with the system library environment)
  3. Compile the project, and finally automatically link the enabled dependency packages

Quick learning

Create an empty project that relies on the tbox library:

$ xmake create -t console_tbox test

$ cd test

Copy the code

If the tbox library is not currently installed, the tbox library will be automatically downloaded and installed.

$xmake

Copy the code

Switch to iphoneOS platform for compilation, and the tbox library of iphoneOS version will be reinstalled for link use:

$xmake f -p iphoneos

$xmake

Copy the code

Switch to arm64-V8A for Android platform

$xmake f -p android [--ndk=~/android-ndk-r16b]

$xmake

Copy the code

Semantic versioning

Xmake’s dependency package management fully supports semantic version selection, such as “~1.6.1”. See semver.org/ for a description of semantic version

Some semantic versions:

add_requires("Tbox 1.6. *"."pcre 1.3.x"."Libpng ^ 1.18")

add_requires("Libpng ~ 1.16"."Zlib 1.1.2 | | > = 1.2.11 < 1.3.0")

Copy the code

The current semantic version parser used by Xmake is the SV library contributed by Uael, which also has detailed instructions on how to write version descriptions. See version descriptions below

Of course, if we have no special requirements for the current version of the dependency package, we can write:

add_requires("tbox"."libpng"."zlib")

Copy the code

This will use the latest known version of the package, or a package compiled from the source code of the master branch. If the current package has a Git repo address, we can also specify a specific branch version:

add_requires("tbox master")

add_requires("tbox dev")

Copy the code

Additional package information Settings

Optional package Settings

If the specified dependency package is not supported by the current platform, or the build installation fails, Xmake will compile an error, which is reasonable for projects that must rely on certain packages to work. However, if some packages are optional dependencies that can be compiled without them, you can set them to optional:

add_requires("tbox", {optional = true})

Copy the code

Disabling system Libraries

By default, xmake will preferentially detect the existence of the system library (if no version requirement is set). If the user does not want to use the system library or the library provided by third-party package management at all, it can be set:

add_requires("tbox", {system = false})

Copy the code

Use the debug version of the package

If we want to source debug dependencies at the same time, we can set it to use the Debug version of the package (provided, of course, that package supports debug compilation) :

add_requires("tbox", {debug = true})

Copy the code

If the package does not support debug compilation, you can submit changes to the compilation rules in the repository to support debug, for example:

package("openssl")

    on_install("linux"."macosx".function (package)

        os.vrun("./config %s --prefix=\"%s\"".package:debug(a)and "--debug" or "".package:installdir())

        os.vrun("make -j4")

        os.vrun("make install")

    end)

Copy the code

Pass additional compilation information to the package

Some packages have various compile options at compile time, which we can pass in, of course, if the package itself supports:

add_requires("tbox", {config = {small=true}})

Copy the code

Pass –small=true to the tbox package so that the compiled installed tbox package has this option enabled.

Use your own private package repository

If the required package is not in the official repository xmake-repo, we can submit contributed code to the repository for support. However, if some packages are only used for personal or private projects, we can set up a private repository repo, which can be organized as xmake-repo

For example, we now have a private repository repo: [email protected]:myrepo/xmake-repo.git

We can add the warehouse by using the following command:

$xmake repo --add myrepo [email protected]:myrepo/xmake-repo.git

Copy the code

Or we could just write it in xmake. Lua:

add_repositories("my-repo [email protected]:myrepo/xmake-repo.git")

Copy the code

If we just want to add one or two private packages, creating a Git repo is too much of a hassle at this point. We can just put the package repository inside the project, for example:

projectdir

  - myrepo

    - packages

      - t/tbox/xmake.lua

      - z/zlib/xmake.lua

  - src

    - main.c

  - xmake.lua

Copy the code

The myrepo directory above is its own private package repository, built into its own project, and then add the repository location to xmake. Lua:

add_repositories("my-repo myrepo")

Copy the code

This can be referenced in the Benchbox project, which has a private repository built in.

We can even define package descriptions directly into the project xmake.lua without building a repository, which is useful if we rely on one or two packages, for example:

package("libjpeg")



    set_urls("http://www.ijg.org/files/jpegsrc.$(version).tar.gz")



    add_versions("v9c"."650250979303a649e21f87b5ccd02672af1ea6954b911342ea491f351ceb7122")



    on_install("windows".function (package)

        os.mv("jconfig.vc"."jconfig.h")

        os.vrun("nmake -f makefile.vc")

        os.cp("*.h".package:installdir("include"))

        os.cp("libjpeg.lib".package:installdir("lib"))

    end)



    on_install("macosx"."linux".function (package)

        import("package.tools.autoconf").install(package)

    end)



package_end()



add_requires("libjpeg")



target("test")

    set_kind("binary")

    add_files("src/*.c") 

    add_packages("libjpeg")

Copy the code

Use the package management command

The package management command $xmake require can be used to manually display the download, compile, install, uninstall, retrieve, and view package information.

Install specified packages

$xmake require tbox

Copy the code

Install the specified version package:

$ xmake require tbox "1.6"

Copy the code

Force a re-download of the installation and display the installation details:

$ xmake require -f -v tbox "1.5.x"

Copy the code

Pass additional Settings:

$ xmake require --extra="debug=true,config={small=true}" tbox

Copy the code

Install the debug package and pass the build configuration information small=true to the package.

Uninstalling the specified package

$xmake require --uninstall tbox

Copy the code

This completely unloads the delete package file.

Removing a specified package

Unlink only specifies the package, which is not detected by the current project, but the package still exists locally and will be completed quickly if reinstalled.

$xmake require --unlink tbox

Copy the code

View package details

$xmake require --info tbox

Copy the code

Search for packages in the current repository

$xmake require --search tbox

Copy the code

This supports fuzzy search and Lua pattern matching search:

$xmake require --search pcr

Copy the code

Pcre, pCRE2, and other packages will be searched simultaneously.

Lists the currently installed packages

$xmake require --list

Copy the code

Use warehouse management commands

As mentioned briefly, adding a private repository can be used (local path addition is supported) :

$xmake repo --add myrepo [email protected]:myrepo/xmake-repo.git

Copy the code

We can also remove an installed repository:

$xmake repo --remove myrepo

Copy the code

Or view all added warehouses:

$xmake repo --list

Copy the code

If there are updates to the remote repository, you can manually perform the repository update to get more and more up-to-date packages:

$xmake repo -u

Copy the code

Submit the package to the official warehouse

At present, this feature has just been completed, there are not many packages in the official warehouse, and some packages may not support some platforms, but this is not too big a problem, I will continue to expand and improve the package warehouse after several iterations.

Xmake-repo: Xmake-repo: Xmake-repo: Xmake-repo: Xmake-repo: Xmake-repo: Xmake-repo: Xmake-repo: Xmake-repo

For a detailed description of contributions, see: CONTRIBUTING.md

For more information on remote dependency packages, see the official documentation: Remote Dependency Patterns

In fact, xmake package management has gone through three generations, the first two versions of V1.0 and V2.0 are local package management mode and system library lookup mode respectively, both of which are very useful in some cases. We don’t need to talk about these two things here. We can read the documentation: dependency package management

conclusion

With that said, let’s finally take a look at some of the other new features and updates:

Other new features

  • New FASM assembler support
  • addhas_config.get_configandis_configInterface to quickly determine options and configuration values
  • addset_configInterface to set default configuration
  • add$xmake --tryTo try to build engineering
  • addset_enabled(false)Disable target to display
  • # 69: Add remote dependency package management,Add_requires (" tbox ~ 1.6.1 ")
  • #216: Add Windows MFC compilation rules

To improve the

  • Improved Qt build environment detection and added support for mingw SDK
  • Add default debug/release rules to xmake.lua generated by automatic scanning
  • #178: Modify the target name under mingw
  • foradd_files()Case insensitive path pattern matching is supported on Windows
  • To improve thedetect.sdks.find_qtProbing for Qt root
  • # 184Improvement:lib.detect.find_packageSupport VCPKG
  • #208: Improved RPATH support for dynamic libraries

Bugs fix

  • #177: Fixed dependency on dynamic library target if basename is set to link failure
  • repair$xmake f --menuExit and the CPU is too high
  • #197: Fixed the generated VS201X project file with Chinese path garbled characters
  • Fixed WDK rule compiler generated driver running blue screen in Windows 7
  • #205: Fixed bug where vcPROj project generated targetDIR, objectdir path Settings mismatch

tboox.org/cn/2018/10/…