Andrew Kelley 5b1a492012
breaking: improve std.fs directory handling API
* Added `std.c.unlinkat` and `std.os.unlinkat`.
 * Removed `std.fs.MAX_BUF_BYTES` (this declaration never made it to
   master branch)
 * Added `std.fs.Dir.deleteTree` to be used on an open directory handle.
 * `std.fs.deleteTree` has better behavior for both relative and
   absolute paths. For absolute paths, it opens the base directory
   and uses that handle for subsequent operations. For relative paths,
   it does a similar strategy, using the cwd handle.
 * The error set of `std.fs.deleteTree` is improved to no longer have
   these possible errors:
   - OutOfMemory
   - FileTooBig
   - IsDir
   - DirNotEmpty
   - PathAlreadyExists
   - NoSpaceLeft
 * Added `std.fs.Dir.posix_cwd` which is a statically initialized
   directory representing the current working directory.
 * The error set of `std.Dir.open` is improved to no longer have these
   possible errors:
   - FileTooBig
   - IsDir
   - NoSpaceLeft
   - PathAlreadyExists
   - OutOfMemory
 * Added more alternative functions to `std.fs` for when the path
   parameter is a null terminated string. This can sometimes be more
   effecient on systems which have an ABI based on  null terminated
   strings.
 * Added `std.fs.Dir.openDir`, `std.fs.Dir.deleteFile`, and
   `std.fs.Dir.deleteDir` which all operate on an open directory handle.
 * `std.fs.Walker.Entry` now has a `dir` field, which can be used to do
   operations directly on `std.fs.Walker.Entry.basename`, avoiding
   `error.NameTooLong` for deeply nested paths.
 * Added more docs to `std.os.OpenError`

This commit does the POSIX components for these changes. I plan to
follow up shortly with a commit for Windows.
2019-10-20 21:48:23 -04:00
2019-10-16 21:16:06 -04:00
2019-10-12 10:57:11 +02:00
2019-10-08 00:06:28 -04:00
2015-08-05 16:22:18 -07:00
2019-09-20 12:58:00 -04:00

ZIG

A general-purpose programming language designed for robustness, optimality, and maintainability.

Resources

Building from Source

Build Status

Note that you can download a binary of master branch.

Stage 1: Build Zig from C++ Source Code

Dependencies

POSIX
  • cmake >= 2.8.5
  • gcc >= 5.0.0 or clang >= 3.6.0
  • LLVM, Clang, LLD development libraries == 9.x, compiled with the same gcc or clang version above
Windows
  • cmake >= 3.15.3
  • Microsoft Visual Studio. Supported versions:
    • 2015 (version 14)
    • 2017 (version 15.8)
    • 2019 (version 16)
  • LLVM, Clang, LLD development libraries == 9.x

Instructions

POSIX
mkdir build
cd build
cmake ..
make install
MacOS
brew install cmake llvm@9
brew outdated llvm@9 || brew upgrade llvm@9
mkdir build
cd build
cmake .. -DCMAKE_PREFIX_PATH=$(brew --prefix llvm)
make install
Windows

See https://github.com/ziglang/zig/wiki/Building-Zig-on-Windows

Stage 2: Build Self-Hosted Zig from Zig Source Code

Note: Stage 2 compiler is not complete. Beta users of Zig should use the Stage 1 compiler for now.

Dependencies are the same as Stage 1, except now you can use stage 1 to compile Zig code.

bin/zig build --prefix $(pwd)/stage2

This produces ./stage2/bin/zig which can be used for testing and development. Once it is feature complete, it will be used to build stage 3 - the final compiler binary.

Stage 3: Rebuild Self-Hosted Zig Using the Self-Hosted Compiler

Note: Stage 2 compiler is not yet able to build Stage 3. Building Stage 3 is not yet supported.

Once the self-hosted compiler can build itself, this will be the actual compiler binary that we will install to the system. Until then, users should use stage 1.

Debug / Development Build

./stage2/bin/zig build --prefix $(pwd)/stage3

Release / Install Build

./stage2/bin/zig build install -Drelease
Description
General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
Readme MIT 711 MiB
Languages
Zig 98.3%
C 1.1%
C++ 0.2%
Python 0.1%