TBOOX Open Source Project

• Xmake v2.8.3 Released, Improve Wasm and Support Xmake Source Debugging

  2023-09-26

  xmake

  xmake  lua  C/C++  package  performance  API  rust

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

  It is very lightweight and has no dependencies because it has a built-in Lua runtime.

  It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.

  We can use it to build project directly 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 integrated use of C/C++ dependent libraries.

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

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

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

  • Github
  • Document

  

  Introduction of new features

  In the new version, we have added breakpoint debugging support for Xmake’s own source code, which can help contributors to get familiar with xmake’s source code more quickly, and also help users to debug and analyse their own project’s configure scripts.

  In addition, the number of packages in our xmake-repo repository is about to exceed 1100, with more than 100 packages added in just one month, thanks to @star-hengxing’s contribution.

  At the same time, we focused on improving build support for Wasm and Qt6 for wasm.

  Breakpoint Debugging Xmake

  In version 2.8.3, we added Lua breakpoint debugging support, with VSCode-EmmyLua plugin, we can easily debug Xmake source code in VSCode breakpoints.

  First of all, we need to install VSCode-EmmyLua plugin in VSCode’s plugin market, and then run the following command to update the xmake-repo repository to keep it up-to-date.

  $ xrepo update-repo
  

  !> Xmake also needs to be kept up to date.

  Then, execute the following command in your own project directory:

  $ xrepo env -b emmylua_debugger -- xmake build
  

  The xrepo env -b emmylua_debugger is used to bind the EmmyLua debugger plugin environment, and the arguments after -- are the actual xmake commands we need to debug.

  Usually we just debug the xmake build build, but if you want to debug other commands, you can tweak it yourself, for example, if you want to debug the xmake install -o /tmp install command, you can change it to:

  $ xrepo env -b emmylua_debugger -- xmake install -o /tmp
  

  After executing the above command, it will not exit immediately, it will remain in a waiting debugging state, possibly without any output.

  At this point, instead of exiting it, let’s go ahead and open VSCode and open Xmake’s Lua script source directory in VSCode.

  That is, this directory: Xmake Lua Scripts, which we can download locally or directly open the lua script directory in the Xmake installation directory.

  Then switch to VSCode’s debugging tab and click RunDebug -> Emmylua New Debug to connect to our xmake build command debugger and start debugging.

  As you can see below, the default start breakpoint will automatically break inside debugger:_start_emmylua_debugger, and we can click on the single-step to jump out of the current function, which will take us to the main entry.

  

  Then set your own breakpoint and click Continue to Run to break to the code location you want to debug.

  We can also set breakpoints in our project’s configuration scripts, which also allows us to quickly debug our own configuration scripts, not just Xmake’s own source code.

  

  阅读中文 Read All

  ---

• Xmake v2.8.2 Released, Official package repository count over 1k

  2023-08-22

  xmake

  xmake  lua  C/C++  package  performance  API  rust

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

  It is very lightweight and has no dependencies because it has a built-in Lua runtime.

  It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.

  We can use it to build project directly 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 integrated use of C/C++ dependent libraries.

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

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

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

  • Github
  • Document

  

  Introduction of new features

  In this release, we’ve added a number of useful APIs, removed some interfaces that were marked as deprecated a few years ago, and improved soname support for dynamic libraries.

  Meanwhile, we’ve had some good news in the meantime: our xmake-repo official repository has surpassed 1k packages, thanks to every contributor to Xmake, which is basically a repository of packages contributed by the community.

  Especially @xq114, @star-hengxing, @SirLynix contributed a lot of packages, thank you very much~.

  Also, the Xmake repository commits have reached 12k, and have been iterating rapidly. Here’s a brief introduction to some of the major updates in the new version.

  Add soname support

  In this release, we have added soname version support to the set_version interface, which is used to control the version compatibility of the so/dylib dynamic library.

  You can configure the soname version suffix, and xmake will automatically generate a symbolic link to execute the specified version of the library when compiling and installing it.

  For example, if we configure:

  set_version("1.0.1", {soname = true})
  

  xmake will automatically resolve the major version of the version number as the soname version, generating the following structure:

  └── lib
      ├── libfoo.1.0.1.dylib
      ├── libfoo.1.0.1.dylib -> libfoo.1.0.1.dylib
      └── libfoo.dylib -> libfoo.1.dylib
  

  Of course, we can also specify soname to a specific version naming:

  set_version("1.0.1", {soname = "1.0"}) -> libfoo.so.1.0, libfoo.1.0.dylib
  set_version("1.0.1", {soname = "1"}) -> libfoo.so.1, libfoo.1.dylib
  set_version("1.0.1", {soname = "A"}) -> libfoo.so.A, libfoo.A.dylib
  set_version("1.0.1", {soname = ""}) -> libfoo.so, libfoo.dylib
  

  And if soname is not set, then soname version control is not enabled by default:

  set_version("1.0.1") -> libfoo.so, libfoo.dylib
  

  阅读中文 Read All

  ---

• Xmake v2.8.1 Released, Lots of Detailed Feature Improvements

  2023-07-11

  xmake

  xmake  lua  C/C++  package  performance  mingw64  wasm

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

  It is very lightweight and has no dependencies because it has a built-in Lua runtime.

  It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.

  We can use it to build project directly 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 integrated use of C/C++ dependent libraries.

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

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

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

  • Github
  • Document

  

  Introduction of new features

  Windows long path problem improvement

  Windows’ long path limitation has always been a big problem. Projects that are nested too deeply may fail when reading or writing files, which affects xmake’s usability and experience.

  Although xmake has provided various measures to avoid this problem, it still suffers from some limitations occasionally. In this release, we have improved the installer by providing an installation option that lets you selectively enable long path support.

  This requires administrator privileges, as it requires a registry write.

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

  Users can decide for themselves, whether they need to turn it on or not.

  Thanks to @A2va for the contribution.

  zypper package manager support

  Added support for OpenSUSE’s zypper package manager, which can be automatically downloaded and installed directly from zypper, and integrates with the packages it provides.

  Thanks to @iphelf for his contribution.

  add_requires("zypper::libsfml2 2.5")
  

  Improve msbuild package installation

  Some third-party packages, which are not maintained by cmake, just provide the vcproj project file, and if we make it into a package, we need to use the tools.msbuild module to compile and install it.

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

  So we have improved the tools.msbuild module to provide automatic vcproj upgrades by specifying the vcproj/sln files that need to be upgraded.

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

  阅读中文 Read All

  ---

• Xmake v2.7.8 released, Improve package virtual environment and build speed

  2023-04-04

  xmake

  xmake  lua  C/C++  package  performance  mingw64  wasm

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

  It is very lightweight and has no dependencies because it has a built-in Lua runtime.

  It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.

  We can use it to build project directly 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 integrated use of C/C++ dependent libraries.

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

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

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

  • Github
  • Document

  

  Introduction of new features

  Quickly switch temporary virtual environments

  Xmake has long supported the virtual environment management of packages, and can switch between different package environments through configuration files.

  We can customize some package configurations by adding the xmake.lua file in the current directory, and then enter a specific package virtual environment.

  add_requires("zlib 1.2.11")
  add_requires("python 3.x", "luajit")
  

  $ xrepo env shell
  > python --version
  > luajit --version
  

  You can also switch environments by importing custom environment configuration files:

  $ xrepo env --add /tmp/base.lua
  $ xrepo env -b base shell
  

  In the new version, we have made further improvements, allowing Xrepo to temporarily specify the list of environment packages that need to be bound directly on the command line to achieve fast switching without any configuration.

  And it supports specifying multiple package environments at the same time.

  For example, we want to enter an environment with python 3.0, luajit and cmake, just execute:

  $ xrepo env -b "python 3.x,luajit,cmake" shell
  [python, luajit, cmake] $ python --version
  Python 3.10.6
  [python, luajit, cmake] $ cmake --version
  cmake version 3.25.3
  

  Xmake will automatically install the relevant dependencies, and then open a new shell environment. There is also a prompt prompt on the left side of the terminal in the new environment.

  If we want to exit the current environment, we only need to execute

  [python, luajit, cmake] $ xrepo env quit
  $
  

  阅读中文 Read All

  ---

• Xmake v2.7.7 released, Support Haiku, Improve API check and C++ Modules

  2023-02-23

  xmake

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

  It is very lightweight and has no dependencies because it has a built-in Lua runtime.

  It uses xmake.lua to maintain project builds and its configuration syntax is very simple and readable.

  We can use it to build project directly 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 integrated use of C/C++ dependent libraries.

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

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

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

  • Github
  • Document

  

  Introduction of new features

  Haiku support

  Xmake is now fully operational on Haiku systems and we have added a haiku compilation platform to Xmake for compiling code on Haiku systems.

  The result is as follows:

  

  阅读中文 Read All

  ---