1. 6
  1.  

  2. 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.

    2. 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.