TBOOX Open Source Project

• Xmake v2.7.6 Released, Add Verilog and C++ Module Distribution Support

  2023-01-22

  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

  Support Verilog Program

  iVerilog Simulator

  Through add_requires("iverilog") configuration, we can automatically pull the iverilog toolchain package, and then use set_toolchains("@iverilog") to automatically bind the toolchain to compile the project.

  add_requires("iverilog")
  target("hello")
       add_rules("iverilog. binary")
       set_toolchains("@iverilog")
       add_files("src/*.v")
  

  Set abstract configuration

  add_requires("iverilog")
  target("hello")
       add_rules("iverilog. binary")
       set_toolchains("@iverilog")
       add_files("src/*.v")
       add_defines("TEST")
       add_includedirs("inc")
       set_languages("v1800-2009")
  

  We can use set_languages("v1800-2009") to set the language standard for switching Verilog.

  Currently supported values and mappings are as follows:

  ["v1364-1995"] = "-g1995"
  ["v1364-2001"] = "-g2001"
  ["v1364-2005"] = "-g2005"
  ["v1800-2005"] = "-g2005-sv"
  ["v1800-2009"] = "-g2009"
  ["v1800-2012"] = "-g2012"
  

  Set custom flags

  add_requires("iverilog")
  target("hello")
       add_rules("iverilog. binary")
       set_toolchains("@iverilog")
       add_files("src/*.v")
       add_values("iverilogs.flags", "-DTEST")
  

  Build the project

  $ xmake
  check iverilog... iverilog
  check vvp... vvp
  [50%]: linking.iverilog hello.vvp
  [100%]: build ok!
  

  Run the program

  $ xmake run
  hello world!
  LXT2 INFO: dumpfile hello.vcd opened, ready for output.
  src/main.v:6: $finish called at 0 (1s)
  

  More complete examples: iVerilog Examples

  Verilator Simulator

  Through add_requires("verilator") configuration, we can automatically pull the verilator toolchain package, and then use set_toolchains("@verilator") to automatically bind to the toolchain to compile the project.

  add_requires("verilator")
  target("Hello")
       add_rules("verilator. binary")
       set_toolchains("@verilator")
       add_files("src/*.v")
       add_files("src/*.cpp")
  

  verilator project, we need an additional sim_main.cpp file to participate in the compilation, as the entry code of the program.

  #include "hello.h"
  #include "verilated.h" (Simplified Chinese)
  
  int main(int argc, char** argv) {
       VerilatedContext* contextp = new VerilatedContext;
       contextp->commandArgs(argc, argv);
       hello* top = new hello{contextp};
       while (!contextp->gotFinish()) { top->eval(); }
       remove top.
       Remove contextp.
       returns 0.
  }
  

  Set abstract configuration

  add_requires("verilator")
  target("Hello")
       add_rules("verilator. binary")
       set_toolchains("@verilator")
       add_files("src/*.v")
       add_defines("TEST")
       add_includedirs("inc")
       set_languages("v1800-2009")
  

  We can use set_languages("v1800-2009") to set the language standard for switching Verilog.

  Currently supported values and mappings are as follows.

  --Verilog
  ["v1364-1995"] = "+1364-1995ext+v".
  ["v1364-2001"] = "+1364-2001ext+v".
  ["v1364-2005"] = "+1364-2005ext+v".
  --system-Verilog
  ["v1800-2005"] = "+1800-2005ext+v".
  ["v1800-2009"] = "+1800-2009ext+v".
  ["v1800-2012"] = "+1800-2012ext+v",
  ["v1800-2017"] = "+1800-2017ext+v".
  

  Set custom flags

  add_requires("verilator")
  target("Hello")
       add_rules("verilator. binary")
       set_toolchains("@verilator")
       add_files("src/*.v")
       add_files("src/*.cpp")
       add_values("verilator.flags", "--trace", "--timing")
  

  Build the project

  $ xmake
  [ 0%]: compiling.verilog src/main.v
  [ 15%]: cache compiling.release /Users/ruki/.xmake/packages/v/verilator/2023.1.10/cd2268409c1d44799288c7759b3cbd56/share/verilator/include/verilated.cpp
  [ 15%]: cache compiling.release build/.gens/hello/macosx/x86_64/release/rules/verilator/hello___024root__Slow.cpp
  [ 15%]: cache compiling.release build/.gens/hello/macosx/x86_64/release/rules/verilator/hello___024root__DepSet_h9053a130__0__Slow.cpp
  [ 15%]: cache compiling.release build/.gens/hello/macosx/x86_64/release/rules/verilator/hello.cpp
  [ 15%]: cache compiling.release /Users/ruki/.xmake/packages/v/verilator/2023.1.10/cd2268409c1d44799288c7759b3cbd56/share/verilator/include/verilated_threads.cpp
  [ 15%]: cache compiling.release build/.gens/hello/macosx/x86_64/release/rules/verilator/hello__Syms.cpp
  [ 15%]: cache compiling.release build/.gens/hello/macosx/x86_64/release/rules/verilator/hello___024root__DepSet_h07139e86__0.cpp
  [15%]: cache compiling.release src/sim_main.cpp
  [ 15%]: cache compiling.release build/.gens/hello/macosx/x86_64/release/rules/verilator/hello___024root__DepSet_h9053a130__0.cpp
  [84%]: linking. release hello
  [100%]: build ok!
  

  Run the program

  $ xmake run
  ruki-2:hello ruki$ xmake run
  hello world!
  - src/main.v:4:Verilog $finish
  

  A more complete example: Verilator

  Support for C++ Module distribution

  Many thanks to Arthapz for continuing to help improve xmake’s support for C++ Modules in this new release.

  We can now distribute C++ Modules as packages for quick integration and reuse in other projects.

  This is a prototype implementation based on the draft design for module distribution in p2473r1.

  Creating a C++ Modules package for distribution

  We start by maintaining a build of the modules using xmake.lua and telling xmake which module files to install for external distribution by specifying ``{install = true}`’’.

  add_rules("mode.release", "mode.debug")
  set_languages("c++20")
  
  target("foo")
      set_kind("static")
      add_files("*.cpp")
      add_files("*.mpp", { install = true })
  

  We then make it into a package that we can commit to the xmake-repo repository, or of course directly into a local package, or a private repository package.

  Here, for testing purposes, we just make it a local package via set_sourcedir.

  package("foo")
      set_sourcedir(path.join(os.scriptdir(), "src"))
      on_install(function(package)
          import("package.tools.xmake").install(package, {})
      end)
  

  Integrating the C++ Modules package

  We then quickly integrate the C++ Modules package for use via the package integration interface with add_requires("foo").

  Since the modules packages for foo are defined in a private repository, we introduce our own package repository via add_repositories("my-repo my-repo").

  If the package has already been committed to the official xmake-repo repository, there is no need to configure it additionally.

  add_rules("mode.release", "mode.debug")
  set_languages("c++20")
  
  add_repositories("my-repo my-repo")
  add_requires("foo", "bar")
  
  target("packages")
      set_kind("binary")
      add_files("src/*.cpp")
      add_packages("foo", "bar")
      set_policy("build.c++.modules", true)
  

  Once the packages are integrated, we can run the ``xmake`’’ command to download, compile and integrate the C++ Modules package for use with one click.

  $ xmake
  checking for platform ... linux
  checking for architecture ... x86_64
  note: install or modify (m) these packages (pass -y to skip confirm)?
  in my-repo:
    -> foo latest
    -> bar latest
  please input: y (y/n/m)
  
    => install bar latest ... ok
    => install foo latest ... ok
  [ 0%]: generating.module.deps src/main.cpp
  [ 0%]: generating.module.deps /mnt/xmake/tests/projects/c++/modules/packages/build/.packages/b/bar/latest/ 4e0143c97b65425b855ad5fd03038b6a/modules/bar/bar.mpp
  [ 0%]: generating.module.deps /mnt/xmake/tests/projects/c++/modules/packages/build/.packages/f/foo/latest/ 4e0143c97b65425b855ad5fd03038b6a/modules/foo/foo.mpp
  [ 14%]: compiling.module.release bar
  [ 14%]: compiling.module.release foo
  [ 57%]: compiling.release src/main.cpp
  [ 71%]: linking.release packages
  [ 100%]: build ok!
  ```''
  
  Note: After each package is installed, a meta-info file for the maintenance module is stored in the package path, this is a format specification agreed in ``p2473r1.pdf``, it may not be the final standard, but this does not affect our ability to use the distribution of the module now.
  
  ```bash
  $ cat . /build/.packages/f/f/foo/latest/4e0143c97b65425b855ad5fd03038b6a/modules/foo/foo.mpp.meta-info
  {"_VENDOR_extension":{"xmake":{"name": "foo", "file": "foo.mpp"}}, "definitions":{}, "include_paths":{}}
  

  The full example project is available at: C++ Modules package distribution example project

  Support for C++23 Std Modules

  Arthapz has also helped to improve support for C++23 Std Modules.

  It is currently supported by three compilers in progress.

  Msvc

  The latest Visual Studio 17.5 preview already supports it, and the non-standard ifc std modules will be deprecated.

  For the standard C++23 std modules, this is how we introduced them.

  import std;
  

  Whereas for ifc std modules, we need to write it like this.

  import std.core;
  

  This is not a C++23 standard, it is only provided by msvc, it is not compatible with other compilers and will be deprecated in new versions of msvc. Therefore the new version of Xmake will only support C++23 std modules and not the deprecated ifc std modules.

  Clang

  It seems that the latest clang does not yet fully support C++23 std modules either, and is still in draft patch status, #D135507.

  However, Xmake does support it, so if you want to try it out, you can merge in the patch and test it with xmake.

  There is also experimental support for non-standard std modules in lower versions of clang.

  It is still possible to experiment with xmake to build std modules in lower versions of clang, even though it is probably still a toy (and will encounter many problems).

  For a discussion see: #3255

  Gcc

  It is not currently supported.

  Xrepo auto-completion support

  Previously, we only supported the incomplete xmake command. In this new version, we also support the incomplete xrepo install command, which This will automatically search the xmake-repo repository for packages to incomplete our install command.

  Many thanks to @glcraft for this contribution.

  $ xrepo install libp
  libpaper libpfm libpng libpqxx libpthread-stubs
  libpcap libplist libpq libpsl
  

  Changelog

  New features

  • #3228: Add support of importing modules from packages
  • #3257: Add support for iverilog and verilator
  • Support for xp and vc6.0
  • #3214: Completion on xrepo install packages

  Changes

  • #3255: Improve clang libc++ module support
  • Support for compiling xmake using mingw
  • Improve compatibility issues with xmake running on win xp
  • Add pure lua json implementation instead of lua-cjson if the external dependencies are enabled

  Bugs fixed

  • #3229: Fix find rc.exe for vs2015
  • #3271: Fix macro defines with spaces
  • #3273: Fix nim link error
  • #3286: Fix compile_commands for clangd
  阅读中文 Read All

  ---

• Xmake v2.7.3 Released, Package Components and C++ Modules Incremental Build Support

  2022-11-08

  xmake

  xmake  lua  C/C++  package  components

  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

  Package component support

  Introduction

  This new feature is intended to enable the integration of specific sub-libraries from a C/C++ package, and is generally used for library component integration in larger packages.

  This is because such packages provide a number of sub-libraries, not all of which are required by the user, and linking them all may be problematic.

  Although, previous versions were able to support the feature of sublibrary selection, e.g.

  add_requires("sfml~foo", {configs = {graphics = true, window = true}})
  add_requires("sfml~bar", {configs = {network = true}})
  
  target("foo")
      set_kind("binary")
      add_packages("sfml~foo")
  
  target("bar")
      set_kind("binary")
      add_packages("sfml~bar")
  

  This is done by custom configuration of each package, but there are some problems with this approach.

  1. sfml~foo and sfml~bar will be installed repeatedly as two separate packages, taking up double the disk space
  2. some common code will be compiled repeatedly, which will affect the efficiency of the installation
  3. if a target depends on both sfml~foo and sfml~bar, there will be link conflicts

  The impact of double-compilation and disk usage can be very high for very large package integrations such as boost, and can even lead to more than N times the disk usage if there are a large number of sub-library combinations.

  To solve this problem, Xmake has added a package component mode, which offers some of the following benefits.

  1. fast integration of any number of components in just one compile, greatly improving installation efficiency and reducing disk footprint
  2. component abstraction, across compilers and platforms, so users don’t need to worry about configuring link order dependencies between each sub library
  3. easier to use

  For more background details see: #2636

  Use package components

  For the user, using package components is very convenient because the user is not required to maintain the package, as long as the package is used, it is configured with the relevant set of components and we can quickly integrate and use it, e.g.

  add_requires("sfml")
  
  target("foo")
      set_kind("binary")
      add_packages("sfml", {components = "graphics"})
  
  target("bar")
      set_kind("binary")
      add_packages("sfml", {components = "network"})
  

  阅读中文 Read All

  ---

• Xmake v2.7.2 released, build third-party libraries more intelligently

  2022-10-09

  xmake

  xmake  lua  C/C++  trybuild  rule  cmake  autoconf

  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

  Building third party libraries more intelligently

  In previous versions, Xmake provided a TryBuild mode that allowed you to use Xmake to try to build third-party projects maintained by autoconf/cmake/meson etc. directly without xmake.lua.

  In effect, this means that Xmake detects the corresponding build system and invokes commands such as cmake to do so, but it will help the user to simplify the configuration operation, plus it will interface with xmake’s cross-compilation toolchain configuration.

  However, this mode has a certain failure rate, which can lead to build failure if, for example

  1. the project code itself is flawed, resulting in a compilation error
  2. the project code does not support the current platform
  3. the build script is flawed
  4. specific configuration parameters are missing
  5. a missing dependency library that needs to be installed by the user
  6. the compiler version is too low and does not support some of the code

  The TryBuild mode usually handles these cases, but in this new version we have introduced a new mechanism to the TryBuild mode to improve the build logic by reusing build scripts from the xmake-repo repository.

  It roughly handles the process in the following way.

  1. execute the xmake command in the third-party source repository directory
  2. xmake gets the directory name and tries to resolve the project name and version
  3. try to match an existing package from the xmake-repo repository
  4. If the match is successful, build directly using the build logic in the package
  5. if no match is made, fall back to the original TryBuild logic

  What is the benefit of this, if the match is successful, we can solve all the problems mentioned above.

  Even if the current project source code does not support a given platform, or if the source code and build script are flawed in some way, Xmake will automatically patch in a specific patch to fix it and bring in the required dependencies to ensure that it will definitely compile in one click.

  Let’s take a look at the libjpeg library as an example.

  The first step is to download the corresponding source code package

  $ wget https://jaist.dl.sourceforge.net/project/libjpeg-turbo/2.1.4/libjpeg-turbo-2.1.4.tar.gz
  $ tar -xvf libjpeg-turbo-2.1.4.tar.gz
  $ cd libjpeg-turbo-2.1.4
  

  Enter the directory and execute the Xmake command

  Xmake will prompt the user if it detects that it is the libjpeg library, and whether to build it as libjpeg 2.1.4.

  ruki-2:libjpeg-turbo-2.1.4 ruki$ xmake
  note: libjpeg-turbo 2.1.4 in xmake-repo found, try building it or you can run ``xmake f --trybuild=` to set buildsystem (pass -y or --confirm=y/n/d to skip confirm)?
  please input: y (y/n)
  

  We hit enter to confirm to continue the build.

  阅读中文 Read All

  ---

• Xmake v2.7.1 Released, Better C++ Modules Support

  2022-08-25

  xmake

  xmake  lua  C/C++  remote  ccache  C++20  Modules  headerunits  fs-watcher

  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 have refactored and improved the C++20 Modules implementation, improved the dependency graph parsing of module files, added support for STL and User HeaderUnits, and made the CMakelists/compile_commands generator support C++ Modules.

  In addition, we’ve added an xmake watch plugin that can monitor current project file updates in real time, automatically trigger incremental builds, or run some custom commands.

  

  阅读中文 Read All

  ---

• Xmake v2.6.6 Released, Support Distributed Compilation and Build Cache

  2022-05-24

  xmake

  xmake  lua  C/C++  remote  ccache  distributed-compilation

  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 version, we have added a lot of heavyweight new features:

  • Distributed compilation
  • Local compilation cache
  • Remote compilation cache

  With these features, we can compile large C/C++ projects faster.

  In addition, they are completely cross-platform, support not only gcc/clang but also msvc, and there is no any third-party dependency except the compiler, which is very convenient to use.

  Therefore, using Xmake is equivalent to using distcc/ccache/sccache at the same time.

  Compared with these third-party tools, Xmake fully supports Windows and msvc, which eliminates platform differences, independent process calls, and the overhead of additional daemon processes.

  In addition to these features, the new version of Xmake also adds support for compiling Keil/C51 projects, as well as support for the nvc/nvc++/nvfortran compilers in the nvidia-hpc-sdk toolchain.

  Support user authentication for remote compilation

  In the last version, we initially supported remote compilation, but did not provide user authentication support, which would bring some security issues. Therefore, in this version, we added user authentication support.

  At present, Xmake mainly provides the following authentication mechanisms. In addition, it is also effective for distributed compilation and remote caching.

  1. Token authentication
  2. Password authentication
  3. Trusted host verification

  Token authentication

  This is also the default recommended method, which is more secure, more convenient to configure and connect, and does not need to enter a password every time you connect.

  When we execute the xmake service command, a server and client configuration file will be generated by default, and a default token will be automatically generated, so the local direct connection does not require any configuration.

  阅读中文 Read All

  ---