# Try building 3rd Sourcecode

Xmake v2.3.1 and above directly interface with other third-party build systems. Even if other projects do not use xmake.lua for maintenance, Xmake can directly call other build tools to complete the compilation. So why use Xmake to call it if the user can directly use a third-party build tool to compile? The main benefits are:

1. Completely consistent behavior, simplifying the compilation process. No matter which other build system is used, you only need to execute the Xmake command to compile. Users no longer need to study the different compilation processes of other tools.
2. Docking the configuration environment of `xmake config`, reusing the platform detection and SDK environment detection of xmake, and simplifying the platform configuration.
3. Docking cross-compilation environment, even for projects maintained with Autotools, you can quickly cross-compile through Xmake.

## Supported build systems

* Autotools (support for cross-compiling with Xmake)
* XCodeBuild
* CMake (support for cross-compiling with Xmake)
* Make
* MSBuild
* Scons
* Meson
* Bazel
* NdkBuild
* Ninja

## Automatically detect build system and compile

For example, for a project maintained using cmake, executing Xmake directly in the project root directory will automatically trigger a detection mechanism, detect CMakeLists.txt, and then prompt the user if cmake is needed to continue compiling.

```sh
$ xmake
note: CMakeLists.txt found, try building it (pass -y or --confirm=y/n/d to skip confirm)?
please input: y (y/n)
-- Symbol prefix:
-- Configuring done
-- Generating done
-- Build files have been written to:/Users/ruki/Downloads/libpng-1.6.35/build
[  7%] Built target png-fix-itxt
[ 21%] Built target genfiles
[ 81%] Built target png
[ 83%] Built target png_static
...
output to/Users/ruki/Downloads/libpng-1.6.35/build/artifacts
build ok!
```

## Seamlessly, using the Xmake command

Currently supports common commands such as `xmake clean`, `xmake --rebuild` and `xmake config` to seamlessly interface with third-party systems. We can directly clean the compiled output files of the cmake-maintained project

```sh
$ xmake clean
$ xmake clean --all
```

If you add `--all` to perform the cleanup, all files generated by autotools/cmake will be cleared, not only the object files. The default `xmake` is docked with incremental build behavior, but we can also force a quick rebuild:

```sh
$ xmake --rebuild
```

## Manually switch the specified build system

If there are multiple build systems under maintenance in a project, such as the libpng project, which comes with Autotools/CMake/Makefile and other build system maintenance, Xmake defaults to using Autotools. If you want to force switch to other build systems, you can execute:

```sh
$ xmake f --trybuild=[autotools|cmake|make|msbuild|..]
$ xmake
```

In addition, the `--trybuild=` parameter is configured to manually specify the default build system, and the subsequent build process will not prompt the user for selection.

## Cross compile fast!

As we all know, although many projects maintained by Autotools support cross-compilation, the configuration process of cross-compilation is very complicated. There are still many differences in different toolchain processing methods, and many pitfalls will be encountered in the process.

Even if you run through a toolchain's cross-compilation, if you switch to another toolchain environment, it may take a long time, but if you use Xmake, you usually only need two simple commands:

::: tip NOTE
At present, CMake/Autotools supports cross-compilation with Xmake.
:::

### Cross compile android platform

```sh
$ xmake f -p android --trybuild=autotools [--ndk=xxx]
$ xmake
```

::: tip NOTE
Among them, the --ndk parameter configuration is optional. If the user sets the ANDROID_NDK_HOME environment variable, or if the ndk is placed in ~/Library/Android/sdk/ndk-bundle, Xmake can automatically detect it.
:::

Isn't it simple? If you think this is not much, then you can directly operate `./configure` to configure cross-compilation. You can see this document for comparison: [Using NDK with other compilation systems](https://developer.android.com/ndk/guides/other_build_systems#autoconf).

To put it bluntly, you probably have to do this, you may not be able to do it once:

```sh
$ export TOOLCHAIN=$NDK/toolchains/llvm/prebuilt/$HOST_TAG
$ export AR=$TOOLCHAIN/bin/aarch64-linux-android-ar
$ export AS=$TOOLCHAIN/bin/aarch64-linux-android-as
$ export CC=$TOOLCHAIN/bin/aarch64-linux-android21-clang
$ export CXX=$TOOLCHAIN/bin/aarch64-linux-android21-clang++
$ export LD=$TOOLCHAIN/bin/aarch64-linux-android-ld
$ export RANLIB=$TOOLCHAIN/bin/aarch64-linux-android-ranlib
$ export STRIP=$TOOLCHAIN/bin/aarch64-linux-android-strip
$ ./configure --host aarch64-linux-android
$ make
```

If it is CMake, cross-compilation is not an easy task. For the Android platform, this configuration is required.

```sh
$ cmake \
     -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake \
     -DANDROID_ABI=$ABI \
     -DANDROID_NATIVE_API_LEVEL=$MINSDKVERSION \
     $OTHER_ARGS
```

For the iOS platform, I did not find a short-answer configuration method, but found a third-party iOS toolchain configuration, which is very complicated: https://github.com/leetal/ios-cmake/blob/master/ios.toolchain.cmake

For MinGW, it is another way. I have been tossing about the environment for a long time, which is very tossing.

After using XMake, whether it is CMake or Autotools, cross-compilation is very simple, and the configuration method is exactly the same, streamlined and consistent.

### Cross compile iPhoneOS platform

```sh
$ xmake f -p iphoneos --trybuild=[cmake|autotools]
$ xmake
```

### Cross-compile MinGW platform

```sh
$ xmake f -p mingw --trybuild=[cmake|autotools] [--mingw=xxx]
$ xmake
```

### Using other cross-compilation toolchains

```sh
$ xmake f -p cross --trybuild=[cmake|autotools] --sdk=/xxxx
$ xmake
```

For more cross-compilation configuration details, please refer to the document: [Cross Compilation](/guide/basic-commands/cross-compilation), except for an additional `--trybuild=` parameter, all other cross-compilation configuration parameters are completely universal.

## Passing user configuration parameters

We can use `--tryconfigs=` to pass additional configuration parameters of the user to the corresponding third-party build system. For example: autotools will be passed to `./configure`, cmake will be passed to the `cmake` command.

```sh
$ xmake f --trybuild=autotools --tryconfigs="-enable-shared=no"
$ xmake
```

For example, the above command passes `--enable-shared=no` to `./configure` to disable dynamic library compilation. In addition, for `--cflags`, `--includedirs` and `--ldflags`, you don't need to pass `--tryconfigs`, you can pass the built-in parameters like `xmake config --cflags=` to pass through.

## Examples of compiling other build system

### General Compilation

In most cases, the compilation method after each docking system is consistent, except for the `--trybuild=` configuration parameter.

```sh
$ xmake f --trybuild=[autotools|cmake|meson|ninja|bazel|make|msbuild|xcodebuild]
$ xmake
```

::: tip NOTE
We also need to make sure that the build tool specified by --trybuild is installed and working properly.
:::

### Building Android JNI programs

If `jni/Android.mk` exists in the current project, then Xmake can directly call NdkBuild to build the jni library.

```sh
$ xmake f -p android --trybuild=ndkbuild [--ndk =]
$ xmake
```

We also provided [xmake-gradle](https://github.com/xmake-io/xmake-gradle) to build the jni library in gradle,
you can see [Use xmake to build JNI in Gradle](/guide/extensions/ide-integration-plugins#gradle-plugin-jni)
