10 ms·
Xmake: A cross-platform build utility based on Lua
- Xeamek 2y agoDamn, looks pretty nice, will definitely give it a shot
- pcranaway 2y agoI started using xmake a few days ago. Not sure if I will use it for new projects (due to CMake being the standard) but I definitely want to. The workflow is amazing and super fast. You just run `xmake create` and it creates your project. Then you can just run xmake and boom, it compiles it in an instant, linking dependencies, without needing to create a CMakeLists.txt, adding a submodule for every dependency you use, including your dependency's cmake file, blah blah (xmake has its own xrepo tool which allows for dependency management in a MUCH easier way)
- helpfulContrib 2y agoI use CMake when I have to, and XMake when I want to. I use CLion for its CMake integration, and recently sought out XMake integration for it as well .. this works so well, I just don't see myself ever going back to CMake willfully. Its just a huge difference in the semantics and ontology required to maintain projects with these tools.
- delta_p_delta_x 2y ago> without needing to create a CMakeLists.txt, adding a submodule for every dependency you use, including your dependency's cmake file, blah blah (xmake has its own xrepo tool which allows for dependency management in a MUCH easier way) You make it sound worse than it really is today. Using submodules for everything is the pre-vcpkg, pre-FetchContent, pre-ExternalProject way of including dependencies—more than half a decade out of date, and arguably more appropriate for GNU Autotools. With CMake and vcpkg, it's not that much harder: add vcpkg as a Git submodule, add a vcpkg.json, and use its CMake toolchain to bootstrap and install packages with find_package(), done. Said vcpkg.json can be as minimal as (taken from my own projects): { dependencies: [ 'spdlog', 'vulkan-sdk-components', 'libpng' ] }
- IshKebab 2y ago> more than half a decade out of date Yes... but as great as vcpkg is, it's still not ubiquitous enough that everything is on it, in the same way that everything is available for Rust via Cargo, or for Python via pip, or for Java/typescript via NPM. So submodules are still used quite a lot.
- delta_p_delta_x 2y ago> but as great as vcpkg is, it's still not ubiquitous enough that everything is on it Completely fair assessment; I wanted to add MIT's krb5 and realised it wasn't on vcpkg. > So submodules are still used quite a lot And this is the wrong solution. The correct one would be to put in the leg-work and write a new portfile[1] and submit it as a PR[2]. [1]: https://learn.microsoft.com/en-gb/vcpkg/get_started/get-started-packaging?pivots=shell-cmd https://learn.microsoft.com/en-gb/vcpkg/get_started/get-star... [2]: https://learn.microsoft.com/en-gb/vcpkg/get_started/get-started-adding-to-registry?pivots=shell-cmd https://learn.microsoft.com/en-gb/vcpkg/get_started/get-star...
- IshKebab 2y ago> And this is the wrong solution. The correct one ... This is not very realistic. I don't want to become a package maintainer of somebody else's library. But I 100% agree that submodules are not good. I'm hoping Pijul will handle that sort of thing better but I haven't tried it.
- delta_p_delta_x 2y ago> This is not very realistic. I don't want to become a package maintainer of somebody else's library. Fair enough; then maybe ask the library developer nicely if they could add vcpkg support. Many C++ libraries de-facto support CMake and vcpkg because these have reached critical mass over the past half-decade or so. I'd say submodules are worse in every metric—you still have to maintain someone else's library (imagine a CVE patch comes through, for instance); submodules themselves are so fragile that they can break your own repo, requiring a full delete + re-clone, and it leads to 'I have this code, I can now make changes to it' which makes updating even harder.
- mid-kid 2y ago> CMake being the standard Maybe for windows, but I haven't seen it be that popular in the linux world?
- josephg 2y agoI’ve used it to build a lot of projects on Linux. Particularly large and complex opensource projects with a lot of dependencies.
- rbanffy 2y agoIt’s used to build the external dependencies for Hercules (the mainframe emulator) but I personally consider it a humongous pain. It might be the reason no Linux distribution seems to dare to package Hercules 4.x
- triblemaster 2y agohttps://isocpp.org/blog/2024/04/results-summary-2024-annual-cpp-developer-survey-lite https://isocpp.org/blog/2024/04/results-summary-2024-annual-... Search for CMake there.
- DrBazza 2y agoSadly, another example of the C++ community zigging when it should have zagged. Cmake now has tooling in all the major IDEs, whereas the other build systems generally don't. Meson and Bazel are build models in CLion but they're relatively new. CMake is the leader at the moment, due to first mover advantage.
- pcranaway 2y agoI've never built C++ code for Windows, and I still am quite familiar with CMake. CMake is dominating across all platforms, sadly
- jandrewrogers 2y agoCMake is widely used even on Linux. I wouldn't call it a "standard", and there are many things about it that are unaesthetic, but it has some of the largest market share among C++ build systems. Most software doesn't swap out build systems, so market share is backward-looking and changes based on what new projects use. I tend to use Meson for C++ because it is much more pleasant to use. Meson is definitely a minority build system, owing in some part to being new-ish, but I see it being used in new projects so it is still growing.
- ykonstant 2y agoThis is genuinely interesting; any experts care to compare the functionality with more standard tools?
- padde 2y agoDoes it scale for large monorepos? That's where CMake hits its limits. With tremendous effort we switched to Bazel, which has brought down configure+build times to less than 1/10.
- scrivanodev 2y agoHow does Bazel help reduce build times?
- phyrex 2y agoIt caches build artifacts in a blob store and just downloads them instead of compiling them where possible
- scrivanodev 2y agoI see, but that's also possible with CMake right? You can use ccache or sccache via -DCMAKE_CXX_COMPILER_LAUNCHER=ccache/sccache.
- actionfromafar 2y agoSure. If you have any doubts at all that you need Bazel, you don’t need Bazel.
- phyrex 2y agoI suppose, but you’d be limited to a small number of supported languages, whereas bazel works for just about anything. Like my sibling commenter noted, you only need it if you really need it.
- lunfard000 2y agoYou are making it sound like it was a compilation process optimization, but it is just CI thing.
- DrBazza 2y agoBuild artifact caching, and also build farm. In the non-Bazel world, that's ccache and distcc https://bazel.build/remote/caching https://bazel.build/remote/caching https://github.com/bazelbuild/bazel-buildfarm https://github.com/bazelbuild/bazel-buildfarm
- robxorb 2y agoLooks very full-featured, surprised I haven't heard of it. Might finally realise simple (Apple-based) command-line builds for macOS/iOS: https://xmake.io/#/guide/project_examples?id=iosmacos-program https://xmake.io/#/guide/project_examples?id=iosmacos-progra... Including signing. It still relies on xcode of course, but if you don't actually need to use xcode to configure or build, that's a big plus.
- d99kris 2y agoXmake gets posted here once in a while, here are some previous discussions: https://news.ycombinator.com/item?id=19610459 https://news.ycombinator.com/item?id=19610459 https://news.ycombinator.com/item?id=22583147 https://news.ycombinator.com/item?id=22583147 https://news.ycombinator.com/item?id=30696061 https://news.ycombinator.com/item?id=30696061
- cbolton 2y agoThanks, I was curious what are the main differences to Meson (the only general build system so far that I enjoyed using). From these past discussions I gathered: Xmake's biggest advantage: it's a single binary (vs Meson requiring Python) Meson's biggest advantage (aside from popularity): it's a declarative DSL rather (vs including a full-blown programming language like Lua in Xmake) (The second point is subjective, I know some think that including a full programming language is a strength but to my eyes it's a downside that largely outweighs the Python dependency.)
- ghosty141 2y ago> Meson's biggest advantage (aside from popularity): it's a declarative DSL rather I personally don't consider this an advantage. We've ran into the limitations of a DSL way too often at work and at this point I prefer just having a plain programming language as an interface. This way you don't have to learn a custom DSL with its own quirsk, you always have the escape hatch of just writing custom code, and it tends to be less quirky.
- __float 2y agoThe "escape hatch" becomes a liability once a project becomes large enough.
- humanrebar 2y agoI find that C and C++ need nontrivial code generation or environment tuning often enough that you really want a Turing complete expression syntax available.
- jokoon 2y agoCan it build a C++ SFML application on windows? I am now annoyed by the claims of those build systems. My own experience is using a visual studio project manually, and writing classic makefile for linux. Those are things I can't avoid learning. The root of the problem is that windows/unix do things differently, but that doesn't change anyone's understanding of how a compiler/linker works. I am against those build system: I need to learn how to use them, and I need to understand how they manage to "reunite" different toolchains. Generally, I would guess I spend less time building something on each system with either visual studio/makefiles, than using a meta-build system. Microsoft is at fault for making things differently, of course, but attempts to reunite platforms are often quite misguided Of course, people who write libraries need those build systems, obviously, although I don't know what any other build system does better than CMake.
- high_na_euv 2y ago>The root of the problem is that windows/unix do things differently, but that doesn't change anyone's understanding of how a compiler/linker works. Or that cpp ecosystem is so fragmented that you have X various compilers, IDEs, debuggers, build systems and package managers. Insanity for anyone who worked in ecosystems like go, c#, rust
- enriquto 2y ago> Insanity for anyone who worked in ecosystems like go, c#, rust On the other hand, I can easily pick a part of the "C ecosystem" that suits me really well, for there is so much choice! In rust, I'm stuck with some conventions that I must learn to love or else. In my case I like rust the language but cannot stand the ecosystem (most notably, the cargo tool). Similar thing for javascript: the language is OK, but the node ecosystem is nuts.
- cpill 2y agoyeah, you get to choose the cutlery when all you really want is to eat.
- mid-kid 2y agoI've seen this one around but not seen anyone use it. What are its advantages over something like meson?
- thealistra 2y agoFrom the readme: Xmake ≈ Make/Ninja + CMake/Meson + Vcpkg/Conan + distcc + ccache/sccache
- coffeeaddict1 2y ago> Supports C++ modules (new in C++20). Hmm, interesting. Has anyone tested this and seen how it compares against CMake's latest versions?
- lunfard000 2y agoNow if only MS would fix VSCode[0] :'( .Come on, the feature if more than half a decade old and this point. 0: https://github.com/microsoft/vscode-cpptools/issues/6302 https://github.com/microsoft/vscode-cpptools/issues/6302
- humanrebar 2y agoC++ modules need a lot of communication between build systems, compilers, packaging environments, and other dev tools like clangd. Given some of that interop isn't available anywhere due to missing or at least unimplemented protocols, I expect XMake is overpromising here. The CMake blogs are more qualified: 1. General named module use: https://www.kitware.com/import-cmake-c20-modules/ https://www.kitware.com/import-cmake-c20-modules/ 2. Importing the std module: https://www.kitware.com/import-std-in-cmake-3-30/ https://www.kitware.com/import-std-in-cmake-3-30/
- coffeeaddict1 2y agoYeah, that was my thought too. I doubt it supports modules as well as CMake 3.30 (which is not amazing btw) but you never know.
- arthapz 2y agoAs the xmake C++ module main contributor, i can affirm that xmake module support is ahead of cmake, i added support for gcc, clang and msvc, headerunits, import std, automatic reuse of bmi when flags are compatible,import module from an external package (like glm or vulkan_hpp) and i’m closely watching compilers repository to support new things before compiler release for clangd i can't do much currently, there is a PR that add some support, i tried it, but doesn't require for now buildsystem intervention For example: add_requires("vulkan-headers", {configs = {modules = true}}) # xmake.lua target("test-vk") set_languages("c++latest") add_files("src/\*.cpp") set_policy("build.c++.modules", true) add_packages("vulkan-headers") // main.cpp import std; import vulkan_hpp; int main() { auto vk_context = vk::raii::Context(); const auto exts = vk_context.enumerateInstanceExtensionProperties(); for(auto &&ext : exts) std::println("{}", std::string{ext.extensionName}); return 0; } // result > xmake f --toolchain=llvm --runtimes="c++_shared" --yes; xmake b checking for platform ... windows checking for architecture ... x64 [ 0%]: <test-vk> generating.module.deps src\main.cpp [ 0%]: <test-vk> generating.module.deps F:\llvm\bin\..\lib\..\share\libc++\v1\std.cppm [ 0%]: <test-vk> generating.module.deps F:\packages\xmake\v\vulkan-headers\1.3.275+0\ae359cf8d45b4d049acf1ae7350e6dc3\modules\b028617b\vulkan.cppm [ 12%]: <test-vk> compiling.module.release std [ 12%]: <test-vk> compiling.module.release vulkan_hpp [ 62%]: compiling.release src\main.cpp [ 75%]: linking.release test-vk.exe [100%]: build ok, spent 5.64s > xmake run VK_KHR_device_group_creation VK_KHR_external_fence_capabilities VK_KHR_external_memory_capabilities VK_KHR_external_semaphore_capabilities VK_KHR_get_physical_device_properties2 VK_KHR_get_surface_capabilities2 VK_KHR_surface VK_KHR_win32_surface VK_EXT_debug_report VK_EXT_debug_utils VK_EXT_swapchain_colorspace VK_KHR_portability_enumeration VK_LUNARG_direct_driver_loading
- stefanos82 2y agoFor a brief moment I thought it was about Premake [1] under a different name, but after checking xmake's Discussions [2] I have found the answer I was looking for. [1] https://en.wikipedia.org/wiki/Premake https://en.wikipedia.org/wiki/Premake [2] https://github.com/xmake-io/xmake/discussions/1863 https://github.com/xmake-io/xmake/discussions/1863
- WhereIsTheTruth 2y agoIf I were to still use C/C++, i'd definitely use xmake, without hesitating I wish more people would embrace it over cmake, I despise cmake so much.. I fully moved to D however, the experience here is night and day, the module system alone makes me not miss C/C++, at all
- danny0z 2y agoxmake also support D and dub.
- WhereIsTheTruth 2y agoThe other great thing about D is you don't need anything like that Example: dmd -i -Isrc/ src/main.d and the compiler will automatically grab files you import, and when you need packages you can rely on dub, compiler is so fast that in most cases you don't need any form of caching, a full rebuild of my game takes less than 1sec
- wffurr 2y agoLooks pretty neat. Probably a lot easier to use than Bazel, unless you need to compile C++ and Java or TypeScript, e.g. for building Android or web apps with a native dependency all from source.
- blacklion 2y agoSpace of software projects' names are so limited... There is (was) xmake already: build tool used by XFree86/x.org before x.org modularization. It was very good, much better than auto*-tools, but didn't get enough traction outside XFree86 project.
- blacklion 2y agoI'm sorry, I cannot treat seriously project with these installation instructions: --- curl -fsSL https://xmake.io/shget.text https://xmake.io/shget.text | bash --- System packet manager? What is it? Never heard about it. It is like copying "src" directory to new name with each change in sources instead using version control system.
- williamcotton 2y agoYou mean a package manager like this? /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
- rbanffy 2y agoWell… Homebrew solves a lot of problems, and is extremely convenient, but the project was never accused of being a reference for good practices. In that space, I tend to prefer MacPorts.
- saurik 2y agoThat's actually very different, as first downloading the code and then executing it all at once removes the ability to differentiate--and then serve different files to--people who are separating the two steps for audit from people who are streaming the one to the other via pipe. This paradigm is still reckless, though, even if you refused to believe in the security arguments: if you "merely" have a transient error during the script response--which might actually cut off only part of the last line you received!!--you shouldn't execute the fragment :/. If you insist on doing this and you don't want it to feel like amateur hour to people like me--people who have a strong innate sense of exception safety--you (at least) need to use the bash -c with substitution and add a variable (so you can catch the error with set -e or &&). (c=$(curl) && bash -c "$c")
- WhereIsTheTruth 2y agoNot everyone can rely on their system package manager for up to date programs xmake is available in many OS, including debian https://sources.debian.org/src/xmake/ https://sources.debian.org/src/xmake/
- mirekrusin 2y agoIsn't zig good tool for this as well? I've seen it being used in passing [0] - is this reasonable thing to do and we may see more of it? [0] https://github.com/ggerganov/llama.cpp/blob/master/build.zig https://github.com/ggerganov/llama.cpp/blob/master/build.zig
- hiccuphippo 2y agoZig is the {cross,}compiler and the build tool and the package retriever (no package repository) all in one.
- nicce 2y agoWhy Zig is better than some other programming language?
- samatman 2y agoIt easily cross-compiles to any target it supports, and natively handles C and C++ dependencies. Much of the complexity of supporting builds in other languages comes from the inclusion of object code in C or C++, so using Zig gives a leg up with that. It also handles caching quite cleanly. I don't think it's an obvious choice for literally everything, at least not yet. But I'd suggest strongly considering it as a build tool for object-code-heavy applications, even if they don't use the Zig language itself.
- mirekrusin 2y agoPeople use it as better c compiler and build system without using zig per se.
- qwerty456127 2y agoI've been always wondering why do we even need specialized build tools and why does the community around every new programming language or framework feel obliged to invent their own, implemented in their native language. Why can't we just write a script in Python or any other scripting language which would fetch the deps, invoke the compilers, run the tests and spit out the package? I can't answer myself because I only have basic theoretical idea of what build tools do, I have always mostly been using IDEs like VisualStudio which do everything behind the scenes in a press of a button.
- mikepurvis 2y agoAcquiring dependencies is a hard problem. There are generic solutions to at least parts of this, stuff like nix and bazel, but most devs choose an “easier” tool that’s tightly integrated with their language ecosystem rather than one that brings a lot of seemingly unneeded upfront complexity.
- BaculumMeumEst 2y agoRequiring nix for a language would be a large barrier for adoption. It will never be straightforward and will always be niche.
- ReleaseCandidat 2y ago> Requiring nix for a language would be a large barrier for adoption. It's a no-go, as it doesn't work on Windows (no, WSL does not count).
- BaculumMeumEst 2y agoFor new languages writing build tools in the language gives you convenient access to meta programming capabilities and removes a dependency (like python in your example)
- humanrebar 2y agoIt could all be python, but you would need many customization points to serve all the use cases needed to build natively compiled code in all its forms. Language ecosystems like Rust and Go, and even Haskell shrink the problem space to a smaller universe to grab dependencies. You can see this by how awkward it would be to build a program containing those three languages. They all have different package repositories and build workflows. C, Fortran, C++ have very rough tools, but the community wants, and often needs, a wide range of dependency management options. Like mixing languages. Or shipping to PYPI. Or integrating with exotic embedded build environments.
- tgz 2y agoIs this another attempt to make a tool like a rust's cargo for c++?
- jgarzik 2y agoGotta be That Guy: Some of the wisdom from the recent XZ backdoor incident was that cmake was a contributing factor, due to its internal complexity. Some of the current trend is to strip out autotools and cmake, and go back to the basics, because modern OS support is a subset of what was relevant 20 years ago.
- JonChesterfield 2y agoI am deeply sick of "compile and run a program to guess stuff about the environment" as a model. Especially in the context of cross compiling and cmake my patience is totally exhausted. I'm not convinced it's necessary any more. When a compiler claims to implement c99, it probably does implement c99. Lots of ugly target dependent hackery is now fixed at source by doing more sensible things in the target and/or the target having died off decades ago. Libuv does horrendous platform specific stuff on targets I don't recognise, in raw C, and it's totally possible to compile it without doing any configure or cmake style nonsense because the platform specific things are in their own source files. 90% of the target specific stuff I can handle by asking the C preprocessor what it's building. The remaining 10% can be specified by editing a header or passing compiler flags or similar. Right now for C libraries I want to depend on I'm patching the source on import to not need any configure check or magic compiler flags, then building every C file separately into an object with the same invocation, and it is working just fine.
- bfrog 2y agosadly so much is tied into cmake with all its eccentricities of being a weird custom macro language, hard to see using anything besides cmake unless I stop using C
- codedokode 2y agoIt seems that C developers tend to use Turing-complete scripts for building instead of a declarative language. Using scripts means that build configuration cannot be processed by automated tools for extraction of information or modification. Why don't you want to use declarative build configuration?
- GrantMoyer 2y agoIn my experience the short answer is that there are no declarative build tools for C or C++. The longer answer is that there are no declarative build tools because all the build tools aim to support all the insane build requirements of existing C or C++ projects. At that point embedding a turing complete scripting language actually makes for simpler build descriptions than some massive declarative system trying to handle all the corner cases. Of course, that raises the question: why don't any C or C++ build tools limit themselves to some sane subset of build requirements? That, I don't have a good answer for.
- mid-kid 2y agoIn general this exists in order to detect features of the target compiler, libraries, platform and etc. A lot of languages can get away with making assumptions, due to either having only one implementation/compiler, supporting very few platforms/architectures or being otherwise insensitive to the environment.
- juxtapose 2y agoI think I'm for Turing-completeness. Let me try to give my reasons... 1. No, using Turing-complete scripts does not prevent information extraction and meaningful automation. You can ask the program to dump useful information, e.g. targets, compiler flags, etc. That's what rizsotto/Bear does for Makefile. CMAKE_EXPORT_COMPILE_COMMANDS is another example. 2. I don't really think you can do anything further with declarative build languages, unless it is a really limited one like JSON or XML. Meson (a relatively advanced one in the space) advocates for non-Turing-completeness, but you still cannot, for example, modify meson build files reliably using an external tool other than a text editor. 3. Complex build configuration usually requires non-trivial computation and/or dynamic dependency graph building. Turing-completeness gives you a possibility and you don't need to wait for build tool upgrades. Comparing Meson to CMake, I find the niceties of Meson are usually not inherently non-TC. That is, you can theoretically reimplement a nicer CMake with all the niceties of Meson, while still being TC.
- makeluasucks 2y ago[flagged]
- emmanueloga_ 2y agore: C/C++ development: anybody using conda/pixi for dependency management? Here's an example of compiling a C++ SDL program using pixi and the SDL dependency from conda-forge [1]. Seems viable as a replacement for things like vckpg [2] which only builds from source. I'm still researching this but it seems like rattler [3] is the tool to use to build/publish packages. The supported repos are: prefix.dev's own hosting, anaconda.org, artifactory or a self-hosted server. -- 1: https://github.com/prefix-dev/pixi/blob/main/examples/cpp-sdl/pixi.toml#L15 https://github.com/prefix-dev/pixi/blob/main/examples/cpp-sd... 2: https://github.com/microsoft/vcpkg https://github.com/microsoft/vcpkg 3: https://prefix-dev.github.io/rattler-build/latest/authentication_and_upload/#uploading-packages https://prefix-dev.github.io/rattler-build/latest/authentica...
- doubloon 2y agoplease explain how you can truly support something like 404020 different OS, architecture, toolchain, and programming languages without automated regression testing every single one of them. and then please tell me what system can run this testing because i would love to see that.