1. 5

    Your last seven submissions were:

    • xmake v2.5.8
    • xmake v2.5.7
    • xmake v2.5.6
    • xmake v2.5.5
    • xmake v2.5.4
    • C/C++ build system, I use xmake
    • xmake v2.5.3

    Stop spamming.

    1. 2

      Someday, I learned Lobste.rs is not very fond of people submitting mostly their own work (a.k.a. self-promoting posts). So I got curious and went to see the author’s submissions.

      Well, out of 89 submissions, 87 are “authored by ruki”, one is not marked but is from their personal blog (therefore, 88 self-authored submissions) and one submission, three years ago, which isn’t self-promoting.

      1. 4

        There are a few people who mostly submit their own stuff (@soatok comes to mind) that the community is fine with, because it’s consistently engaging and high quality. But even then I think it’s good etiquette to also submit and comment on other stories. I try to keep the ratio of my stuff : other stuff below 1:4.

        I think at one point @pushcx estimated that frontpaging on Lobsters drives as much traffic as tens of thousands in marketing budget.

        1. 3

          What chafes me it’s basically very minor releases. If it’s a big headlining release, OK (assuming you also submit other stuff…). If it’s chump change, why bother except for the clicks?

          1. 2

            I don’t think this is a small version change. I have a lot of new features and improvements for each version, and I also introduce them in detail in the article.

            In addition, I only submit an update every few months, and it is not very frequent. And I see that other shorter versions of articles are allowed. Why my article is considered spam, I am very confused, such as this one, https://lobste.rs/s/hjge7k/python_release_3_10_0 https://lobste.rs/s/qj806e/zig_0_8_0_release_notes https://lobste.rs/s/prutnh/zig_v0_7_0_released https://lobste.rs/s/oln4mx/llvm_13_released

            Well, if you are bored with this, I will not submit them in the future, I am very sorry.

            1. 3

              I don’t think this is a small version change. I have a lot of new features and improvements for each version, and I also introduce them in detail in the article.

              No doubt it seems that way to you, as you are the software author. But to us the changes are minor, sorry :(

              In addition, I only submit an update every few months, and it is not very frequent. And I see that other shorter versions of articles are allowed. Why my article is considered spam, I am very confused, such as this one, https://lobste.rs/s/hjge7k/python_release_3_10_0 https://lobste.rs/s/qj806e/zig_0_8_0_release_notes https://lobste.rs/s/prutnh/zig_v0_7_0_released https://lobste.rs/s/oln4mx/llvm_13_released

              Thing is, those who submit those posts don’t submit only those release notes. If someone came along from the Python project and submitted a story for every single minor release Python ever did, and only submitted those, well, it wouldn’t be very nice, even if those versions of python had some great features.

              Well, if you are bored with this, I will not submit them in the future, I am very sorry.

              I wouldn’t mind the occasional post detailing something novel about xmake, or the very occasional major release notes. But it would be nice if you participated in other ways as well.

    1. 3

      I was put off xmake by the fact that it seems to strongly encourage the antipattern of building from within the source directory. Separate build directories have a lot of advantages:

      • The build configuration can be stored in the build directory so it’s easy to keep multiple build configurations around at the same time.
      • The build can run without the privileges required to write to the source directory, which prevents bugs in the build system from trampling over changes.
      • You don’t need to put a load of things in .gitignore and equivalent for build artefacts and then have exemptions if you actually do need to ship a file of the same type as a build artefact, so your revision control system integration is simpler.
      • Overlapping with the last two points: if your build never modifies anything in your source tree, your revision control system doesn’t have to roll things back or do partial-file commits and your dependency tracking is simplified (if you need to modify a file in the build, don’t modify in-place, modify a copy in the build directory and then add the output as the dependency for the other things).
      • If your source tree is immutable for the build, you can replicate it easily for distributed builds with aggressive local caching.
      • You can have different backup and FS properties for source and build directories. For example, I turn off fsync to the ZFS filesystem mounted in ~/builds because everything in a build directory can be recreated from source and so I don’t care if I lose some data there in the event of a system crash.

      It looks as if the io.replace example here is explicitly patching the source files. I’d be very nervous of a build system that makes this something that’s easy to do. It’s encouraging you to make the kinds of build systems that people will grumble about when they have to maintain them in a decade’s time.

      1. 4

        you can do build in non-source directory.

        cd /tmp/otherdir
        mkdir .xmake
        xmake -P /home/projectdir
        
        1. 1

          You can, but the docs all discourage this and at least some of the things in this article won’t work correctly if you do. It’s clearly a build system that’s been designed for in-tree builds and then had support for out-of-tree builds added, rather than one that’s thought about builds with immutable sources from the start.

      1. 2

        This seems awfully similar to https://lobste.rs/s/feptmd/use_xmake_build_c_c_zig_projects. One is the project xmake and one is the same projects docs.

        1. 1

          Ok, I see.

        1. 3

          On a high level, what the difference between xmake, CMake, and Makefile? Do they aim to solve different problems, or do they solve the very same problem in different ways?

          1. 3

            xmake = make + package manager + generator

            cmake only is a generator

            1. 1

              I see. From my understanding, package managers reply on an eco-system, so you need to convince others to speak your language, just like CMake requires dependency libraries to provide a FindLibFoo.cmake file. How do you encourage external library maintainers to maintain an additional tool-specific build script for xmake, given that we already have Makefile, apt/yum/pkg-config as a package manager, and CMake/Meson as a generator?

              In other words, what’s the killer feature of xmake to justify the cost of adopting it? Maybe the existing build system is neither convenient nor intuitive, but people have already invested a lot of time to get familiar with it, and they need a really good reason to switch their tooling when their upstream and downstream mostly speak, say, CMake.

              1. 2

                The package management of xmake supports more platforms and can also install C/C++ packages for cross-compilation platforms. At the same time, it also supports semantic versions and distributed repository. Users can quickly build their own private package warehouses or define packages directly in the project.

                While vcpkg has just recently supported version selection, conan’s package management does not seem to support semantic version, for example: zlib >=1.2.11, zlib 1.2.*

                Xmake’s package management and xmake build can be seamlessly integrated, and can support custom configuration installation packages.

                add_requires("ffmpeg", {shared = true, debug = true, configs = {libx264 = true}})
                

                In addition, xmake does not have to persuade users to switch to the xmake package repository, because xmake also supports to install packages from third-party package managers, for example: conan/vcpkg/clib/pacman/brew

                Their integration methods are exactly the same, so for users, they are completely free to choose which repository package to use.

                add_requries("conan::openssl/1.1.1g") - use conan packages
                add_requires("vcpkg::openssl") - use vcpkg packages
                add_requires("pacman::zlib") - use pacman packages
                add_requires("brew::zlib") - use homebrew packages
                add_requires("openssl", "zlib") - use xmake packages
                

                Moreover, xmake will automatically detect whether the required package has been installed on the system first, and if it has been installed, xmake will also use it directly.

                1. 1

                  Cool! Can you recommend some tutorials on getting started with xmake? The quick start page is too terse, whereas the paid course is probably outdated considering the rapid development cycle of the project.

                  1. 2

                    Sorry, there is still a lack of English courses. I think that if you look at a few project examples using xmake, you might get started more quickly.

                    Some project examples:

                    Then go to the api manual of the xmake document to view the api usage

                    Or you can use xmake create test command to create an empty project fastly. see https://xmake.io/#/guide/project_examples

          1. 1

            Looks neat, I’d love to see a bunch of the dialog-based FreeBSD utilities (e.g. bsdconfig) rewritten with this. That said, one of the nice things about dialog is the ability to replace it with xdialog and get an equivalent X11 application. Is the layering in this designed to allow graphical back ends to be plugged in?

            1. 1

              Currently only curses/ncurses are supported.

            1. 1

              There’s no actual code on the github linked to this, one has to click through to another repository

              1. 1

                Because it is implemented based on xmake, xrepo is just a wrap script, all implementations are in xmake, so as long as xmake is installed, the xrepo command can be used directly.

              1. 1

                I’ve just fallen in love with Lua over the last few weeks by way of TIC-80 and it’s super great to see things like this that help broaden out the Lua ecosystem.

                Can I ask a related but not exactly on topic question? Which Lua distro do you favor / recommend for Windows? The only one I’ve seen thus far seems to want me to install the entire MingW toolchain in order to install any LuaRocks and I’m reluctant to do that (Maybe I shouldn’t be!).

                1. 2

                  You can try winlua, but I haven’t used it either.

                1. 2

                  @ruki are you the dev? Maybe you can opt in to Hacktoberfest and get some motivated individuals to write some LDoc or similar annotations for the project. I’d love to jump in, but without some more comprehensive docs I wouldn’t know where to begin. Looks great though

                  1. 1

                    Yes, but I don’t have much time to write documents. You can directly refer to all examples in the tests directory. And thank you very much for your suggestions.

                    1. 1

                      I understand the dilemma. There’s a gang of people looking to complete Hacktoberfest, and would probably write (at least some of) those annotations for you if you opt-in and throw some issues up for completing them. Might as well cash in on free help while it’s available.

                      1. 1

                        Thanks, I will consider to use LDoc to generate documents. https://github.com/tboox/ltui/issues/13

                        Although Hacktoberfest seems very interesting, I still don’t know how to organize and create events, and I don’t think anyone will participate in my project.

                  1. 2

                    @ruki, I respect your tenacity.

                    1. 1

                      Thanks!

                    1. 1

                      @ruki, Features wise it looks great. The idea of abstracting most common operations for different compilers (Like the optimization level) is great.

                      What I don’t find satisfying is the documentation. I find meson documentation to be clearer. Also it would be great to define the defaults you set for each compiler.

                      1. 1

                        Thank you very much for your feedback, we will continue to improve the documentation.

                        1. 1

                          We can apply add_rules("mode.release","mode.debug") to set the defaults

                        1. 1

                          That links to a nonexistent github wiki page. Perhaps you meant to link here instead?

                          1. 1
                            1. 1

                              oh, I posted a wrong link, but I can’t modify it

                              1. 1

                                But I added a new link to fix it.

                          1. 1

                            TIL there is a new “xmake” that is completely unrelated to the old (X11) xmake. Wiki doesn’t even mention the old one – I started to think it never really existed, and I was experiencing the Mandela effect, but there is still some evidence here: https://freebsd.pkgs.org/11/freebsd-amd64/xmake-1.06_1.txz.html

                            I guess there are only a thousand possible project names.

                            1. 1

                              They are completely unrelated, just the same name.

                            1. 1

                              xmake looks really interesting and is something I’ll probably consider for my next project (especially if the FreeBSD package is updated). The documentation that I’ve seen so far all does in-tree builds though, which is probably the worst antipattern in build-system design. Are they any docs for driving the build from the build directory?

                              1. 1

                                The documentation that I’ve seen so far all does in-tree builds though, which is probably the worst antipattern in build-system design. Are they any docs for driving the build from the build directory?

                                ? I do not understand it.

                                1. 1

                                  @david_chisnall is asking if it is possible to build in a different directory than the directory with the source code. A good test for this is: “can I mount the source on a read-only filesystem, and compile somewhere else?” This is often useful for people who work on multiple branches in a large codebase, or CI systems for large codebases which heavily rely on caching.

                                  1. 2

                                    oh, it is supported. xmake will not write any files to the source directories by default, only write some target and cache files in curdir/build, tmp, curdir/.xmake and ~/.xmake directories, but we can also modify the location of these directories.

                                    modify global and local cache directory

                                    export XMAKE_GLOBAL_DIR=/xxx
                                    export XMAKE_CONFIG_DIR=/yyy
                                    

                                    modify tmpdir

                                    export XMAKE_TMP_DIR=/ttt
                                    

                                    modify the build output directory:

                                    xmake f --buildir=xxx
                                    xmake
                                    
                                    1. 3

                                      ~/.xmake

                                      Please, use XDG Base Directory instead.

                                  2. 1

                                    All of the examples (unless I am misreading them, please correct me if I’m wrong) run xmake from the source directory. Modern build systems drive the build from the build directory. This has a number of advantages:

                                    • The source directory can be on a read-only or write-is-expensive filesystem (e.g. an aggressively cached local copy of a slow network filesystem), whereas the build directory can be on fast throw-away storage (e.g. the local SSD on a cloud VM).
                                    • It’s easy to have different backup policies for the source and build directories.
                                    • Your per-build configuration is stored in the build directory, so you can easily rerun.
                                    • A completely clean build, even in the presence of build-system bugs, is trivial to do by simply deleting the build directory.
                                    • You don’t need to add a load of things to .gitignore for build outputs and it’s really easy to keep your source tree clean.
                                    • If you have generated source files, it’s trivial to tell the generated ones apart from the others (the generated ones are only in the build directory, not the source tree).

                                    With CMake (which has many other problems), the normal workflow is:

                                    1. Create a new build directory.
                                    2. Run ccmake to configure the build with all of the options that you want.
                                    3. Run ninja to build it.

                                    You can repeat these steps for multiple build configurations and you can build each independently. For example, for LLVM I have a release build and a debug+ASan build that I can link against, and when I’m writing something that depends on LLVM libraries I will do the same thing and have a release build and a debug build with ASan. When I want rapid edit-compile-test cycles, I use the release build, but as soon as something goes wrong I switch to the ASan version and get much more useful debugging information.

                                    In contrast, the instructions that I read for xmake said to run xmake in the source directory. This makes me really nervous, because it remind me of the bad old days when you ran make in your source directory and got a load of generated files interleaved.

                                    The tool I would like is something that I can use in the same way that I use CMake but where the input language is not a horrible macro language that’s been gradually extended and where there is clean layering in the standard library with nothing hard-coded in the tool (for example, the way CMake hard codes the flags that it passes to cl.exe).

                                    1. 2

                                      Although xmake runs by default in the root directory of the project with the xmake.lua file, it will not write any files to the source directory. All files will be generated in a separate build directory.

                                      cd projectdir
                                      xmake
                                      

                                      It will generate ‘build’ and ‘.xmake’ directories to projectdir.

                                      But the build directory can also be modified.

                                      cd projectdir
                                      xmake f --buildir=/tmp/build
                                      xmake
                                      

                                      But xmake still generate .xmake directory to projectdir/.xmake

                                      we can also do not generate .xmake to projectdir

                                       export XMAKE_CONFIG_DIR=/tmp/build/cache
                                      xmake f --buildir=/tmp/build
                                      xmake
                                      

                                      Now, even xmake is still running under the project directory, but the project directory will always be very clean.

                                      In addition, xmake can also not run under the project directory.

                                       cd otherdir
                                       xmake -P projectdir
                                      
                                      1. 1

                                        Thanks, it sounds as if it can do what I want. It’s a shame that the documentation and default behaviour encourages bad style though.

                                1. 2

                                  does it enable building iphone apps without having a Mac? or is a mac computer still needed?

                                  1. 3

                                    It need mac and xcode.

                                  1. 1

                                    I think Stroustrup’s quote about there only being two kinds of languages applies to build systems as well. I must admit I haven’t looked into xmake much yet, are there any larger projects using it?

                                    There is an excellent talk by Jussi Pakkanen (Meson) from CppCon 2019 about the rabbit hole of complexity build systems have to handle.

                                    1. 3

                                      Yes, there are not many larger projects using it at present, because I didn’t do much to promote it.

                                      But there are still some outstanding projects using xmake.

                                      https://github.com/tboox/tbox https://github.com/idealvin/co https://github.com/acl-dev/acl … see more https://github.com/xmake-io/awesome-xmake/blob/master/README.md#projects

                                    1. 2

                                      I’ve been putting up with CMake for years, in our complex cross-platform (pretty much every major platform) C++ codebase. Xmake looks wonderful … as though someone finally listened to my rant about how build systems should use a real programming language instead of awkwardly extending their syntax into a pidgin.

                                      Is it as good as it looks on the surface?

                                      1. 2

                                        I keep hoping that Jon will finish Fabrique. I like the fact that CMake + Ninja has a clean separation of responsibility, one doing responsible for configuring a build, the other responsible for running that build as fast as possible. This means that it’s possible for CMake to export IDE projects if I want a richer debugging experience. Ninja itself is great and I don’t see any point in trying to recreate it. The nicest thing I can say about CMake is that it’s not autoconf.

                                        CMake is a macro system, so everything is a string. Sometimes you interpret it as a number (which is fun when it’s a version string like 10.10 vs 10.2) or a list (with the inherent problem of using a valid character as the list separator). CMake also randomly hard-codes things. For example, the back end to use the Visual Studio compiler always passes /TC or /TP (C or C++ input), so if you want to compile Objective-C on Windows with clang-cl from a CMake build system you have to use an undocumented feature of the clang driver intended for debugging to tell it to remove these flags: they don’t appear in any variable visible in your CMake scripts.

                                        In contrast, Fabrique is a strongly typed language with high-level types such as files (so your build system has enough information to drive a sandboxing framework, for example), actions, lists, and so on, along with functions. It is designed to be possible to drive from an IDE’s GUI or a configuration file and includes concepts such as modules and delegation so you can easily express ideas such as ‘the C compiler flags in this module should be these, plus any from the command line, but not the ones from the parent directory’ (at least, in the design - this is missing so far) and, because those options are passed as a list (not a string), they’re easy to filter without having to escape / unescape.

                                        If anyone finds build system generators interesting and has spare time, please contriute to Fabrique! The design is great, the implementation is incomplete and I don’t think Jon has had time to work on it for over a year.

                                        1. 1

                                          Yes, you can try it.

                                          1. 1

                                            Xmake doesn’t generate VS projects which I think is why CMake is still so popular. vcpkg supports CMake out of the box. I was wrong see below.

                                            1. 1

                                              xmake also support to generate vs projects, cmakelists, build.ninja, makefile, compile_commands and etc. You can see https://xmake.io/#/plugin/builtin_plugins?id=generate-visualstudio-project

                                              xmake project -k vs 
                                              xmake project -k vsxmake (generate vsproject and wrap xmake, recommanded)
                                              

                                              And xmake also support vcpkg, conan, clib, homebrew packages. You can see https://xmake.io/#/package/remote_package?id=add-a-vcpkg-dependency-package

                                              1. 1

                                                Awesome, it’s been a while since I looked again and I should have checked it :)

                                                1. 1

                                                  It’d be lovely if it generated Xcode projects too.

                                            1. 6

                                              I was curious about xmake architecture so I looked into the source code.

                                              xmake doesn’t “require” or “depend upon” Lua. Instead, xmake embeds Lua. Specifically it embeds LuaJIT 2.1, based on what I could tell in their repo source.

                                              So, when you run xmake, you’re actually running a a full-blown Lua implementation that is self-contained in the xmake binary, that has some automatic imports for the xmake embedded build DSL. If you want to run arbitrary Lua using xmake, there is a built-in “lua” plugin, shorthand “xmake l”, described here: https://github.com/xmake-io/xmake/blob/master/README.md#run-

                                              So, it would be a bit like if you built a build language atop Python, but rather than depending on Python, you made your whole build tool embed the entire CPython interpreter, pinned to some version. Lua is used in this way more commonly than Python is, of course.

                                              This means xmake itself is just a C program with large submodules written in Lua, running inside that embedded Lua context. The upside here is that xmake’s releases are just plain platform-specific native binaries that bundle everything you need, and that make no assumptions about your base system. This is a nice benefit in a build tool, as it aids in reproducible builds.

                                              Seems like a pretty fun, fascinating, and practical project. Especially given the confusion around builds and the plethora of language-specific build tools – there are 10 or so popular build tools for JavaScript alone!

                                              1. 3

                                                Instead, xmake embeds Lua.

                                                Isn’t that sort of the main purpose of Lua, to be embedded like this?

                                                1. 2

                                                  Yes, it is completely independent.

                                                  1. 1

                                                    Out of interest. Could it run with different (non-C) Lua implementation? Because I find it interesting to check out if this would work with luerl for using as a “semi-native” build tool in Erlang.

                                                1. 1

                                                  Link seems to be broken and redirects to a url shortener.

                                                  1. 1

                                                    This is because the original address could not be submited. I tried using shorturl, but it seems to be invalid soon. I’m very sorry.

                                                    1. 1

                                                      You have hit the limit of number of submissions from one domain from a single user. DM @pushcx about this.

                                                      Don’t use a link shortener, and don’t create alt accounts to get around this. Your account may be banned.

                                                      As a workaround, talk to people in the IRC chat, someone there can link.

                                                      1. 1

                                                        You have hit the limit of number of submissions from one domain from a single user. DM @pushcx about this.

                                                        Don’t use a link shortener, and don’t create alt accounts to get around this. Your account may be banned.

                                                        As a workaround, talk to people in the IRC chat, someone there can link.

                                                        Got it, thanks!

                                                  1. 1

                                                    The lack of comprehensive documentation in xmake is what stops me from diving into it. Examples are fine, but they aren’t everything.

                                                      1. 1

                                                        That first one is not a documentation at all, more like introductory README.

                                                    1. 1

                                                      Support to install and use multi-platform dependent package (android, iphoneos and etc). see https://github.com/xmake-io/xmake-repo/blob/master/packages/z/zlib/xmake.lua#L12-L29