Giter Site home page Giter Site logo

rules_d's Introduction

Build status

D rules

Status

We make sure this repository works with the latest version of Bazel, but no other development is planned.

Volunteers are welcome. If you want to use the rules, consider contributing to this repository and becoming a maintainer.

Rules

Setup

To use the D rules, add the following to your WORKSPACE file to add the external repositories for the D toolchain:

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
    name = "io_bazel_rules_d",
    urls = ["https://github.com/bazelbuild/rules_d/archive/bcf137e3c9381545ce54715632bc1d31c51ee4da.tar.gz"],
    sha256 = "a32847bf2ae634563dece49c4dc8353956b64ba5c2d01ce811ea243e1a21b5b7",
    strip_prefix = "rules_d-bcf137e3c9381545ce54715632bc1d31c51ee4da",
)

load("@io_bazel_rules_d//d:d.bzl", "d_repositories")
d_repositories()

Roadmap

d_library

d_library(name, srcs, deps, includes, linkopts, versions)
Attributes
name Name, required

A unique name for this rule.

This name will be used as the name of the library built by this rule.

srcs List of labels, required

List of D .d source files used to build the library.

deps List of labels, optional

List of libraries to be linked to this library target.

These can either be other d_library targets, source-only d_source_library targets, or cc_library targets if linking a native library.

imports List of strings, optional

List of import dirs to add to the compile line.

These will be passed to the D compiler via -I flags.

linkopts List of strings, optional

List of flags that are added to the D linker command.

These will be passed to the D compiler via -L flags.

versions List of strings, optional

List of versions to be defined during compilation.

Versions are used for conditional compilation and are enabled in the code using version condition blocks. These versions listed here will be passed to the D compiler using -version flags.

Example

Suppose you have the following directory structure for a D project:

[workspace]/
    WORKSPACE
    foo/
        BUILD
        foo.d
        bar.d
        baz.d

The library foo is built using a d_library target:

foo/BUILD:

load("@io_bazel_rules_d//d:d.bzl", "d_library")

d_library(
    name = "foo",
    srcs = [
        "foo.d",
        "bar.d",
        "baz.d",
    ],
)

d_source_library

d_source_library(name, srcs, deps, includes, linkopts, versions)
Attributes
name Name, required

A unique name for this rule.

srcs List of labels, required

List of D .d source files that comprises this source library target.

deps List of labels, optional

List of library targets depended on by this target.

These can either be other d_source_library targets or cc_library targets, such as when this source library target implements the D interface for a native library. Any native libraries will be linked by d_library targets that depend on this target.

imports List of strings, optional

List of import dirs to add to the compile line.

These will be passed to the D compiler via -I flags for any d_library targets that depend on this target.

linkopts List of strings, optional

List of flags that are added to the D linker command.

These will be passed to the D compiler via -L flags for any d_library targets that depend on this target.

versions List of strings, optional

List of version flags to be defined during compilation.

Versions are used for conditional compilation and are enabled in the code using version condition blocks. These versions listed here will be passed to the D compiler using -version flags for any d_library targets that depend on this target.

Example

Suppose you have the following directory structure for a project building a C library and a D interface for the C library:

[workspace]/
    WORKSPACE
    greeter/
        BUILD
        native_greeter.c
        native_greeter.h
        native_greeter.d
    hello_world
        BUILD
        hello_world.d

Build the C library using the cc_library rule and then use the d_source_library to define the target for the D interface for the C native_greeter library:

greeter/BUILD:

load("@io_bazel_rules_d//d:d.bzl", "d_source_library")

cc_library(
    name = "native_greeter_lib",
    srcs = ["native_greeter.c"],
    hdrs = ["native_greeter.h"],
)

d_source_library(
    name = "native_greeter",
    srcs = ["native_greeter.d"],
    deps = [":native_greeter_lib"],
)

Other targets can directly depend on the d_source_library target to link the C library:

hello_world/BUILD:

load("@io_bazel_rules_d//d:d.bzl", "d_source_library")

d_binary(
    name = "hello_world",
    srcs = ["hello_world.d"],
    deps = ["//greeter:native_greeter"],
)

d_binary

d_binary(name, srcs, deps, includes, linkopts, versions)
Attributes
name Name, required

A unique name for this rule.

This name will be used as the name of the binary built by this rule.

srcs List of labels, required

List of D .d source files used to build the binary.

deps List of labels, optional

List of libraries to be linked to this binary target.

These can either be other d_library targets, source-only d_source_library targets, or cc_library targets if linking a native library.

imports List of strings, optional

List of import dirs to add to the compile line.

These will be passed to the D compiler via -I flags.

linkopts List of strings, optional

List of flags that are added to the D linker command.

These will be passed to the D compiler via -L flags.

versions List of strings, optional

List of versions to be defined during compilation.

Versions are used for conditional compilation and are enabled in the code using version condition blocks. These versions listed here will be passed to the D compiler using -version flags.

Suppose you have the following directory structure for a D project:

[workspace]/
    WORKSPACE
    hello_lib/
        BUILD
        greeter.d
    hello_world
        BUILD
        hello_world.d

The source file hello_lib/greeter.d defines a module greeter:

module greeter;
...

The hello_lib library is built using a d_library target:

hello_lib/BUILD:

load("@io_bazel_rules_d//d:d.bzl", "d_library")

d_library(
    name = "hello_lib",
    srcs = ["greeter.d"],
)

By default, import paths are from the root of the workspace. Thus, the source for the hello_world binary, hello_world.d, would import the greeter module as follows:

import hello_lib.greeter;

However, this can be changed via the imports attribute on the d_library rule.

The hello_world binary is built using a d_binary target:

hello_world/BUILD:

load("@io_bazel_rules_d//d:d.bzl", "d_library")

d_binary(
    name = "hello_world",
    srcs = ["hello_world.d"],
    deps = ["//hello_lib"],
)

d_test

d_test(name, srcs, deps, includes, linkopts, versions)
Attributes
name Name, required

A unique name for this rule.

This name will be used as the name of the test built by this rule.

srcs List of labels, required

List of D .d source files used to build the test.

deps List of labels, optional

List of libraries to be linked to this test target.

These can either be other d_library targets, source-only d_source_library targets, or cc_library targets if linking a native library.

imports List of strings, optional

List of import dirs to add to the compile line.

These will be passed to the D compiler via -I flags.

linkopts List of strings, optional

List of flags that are added to the D linker command.

These will be passed to the D compiler via -L flags.

versions List of strings, optional

List of versions to be defined during compilation.

Versions are used for conditional compilation and are enabled in the code using version condition blocks. These versions listed here will be passed to the D compiler using -version flags.

Example

Suppose you have the following directory structure for a D project:

[workspace]/
    WORKSPACE
    hello_lib/
        BUILD
        greeter.d
        greeter_test.d

hello_lib/greeter.d:

module greeter;

import std.stdio;
import std.string;

class Greeter {
 private string greeting;

 public:
  this(in string greeting) {
    this.greeting = greeting.dup;
  }

  string makeGreeting(in immutable string thing) {
    return format("%s %s!", this.greeting, thing);
  }

  void greet(in immutable string thing) {
    writeln(makeGreeting(thing));
  }
}

hello_lib/greeter_test.d:

import hello_lib.greeter;

unittest {
  auto greeter = new Greeter("Hello");
  assert(greeter.makeGreeting("world") == "Hello world!");
}

void main() {}

To build the library and unit test:

hello_lib/BUILD:

load("@io_bazel_rules_d//d:d.bzl", "d_library", "d_test")

d_library(
    name = "greeter",
    srcs = ["greeter.d"],
)

d_test(
    name = "greeter_test",
    srcs = ["greeter_test.d"],
    deps = [":greeter"],
)

The unit test can then be run using:

bazel test //hello_lib:greeter_test

d_docs

d_docs(name, dep)
Attributes
name Name, required

A unique name for this rule.

dep Label, required

The label of the target to generate code documentation for.

d_docs can generate HTML code documentation for the source files of d_library, d_source_library, d_binary, or d_test targets.

Example

Suppose you have the following directory structure for a D project:

[workspace]/
    WORKSPACE
    foo/
        BUILD
        foo.d
        bar.d
        baz.d

The foo/ directory contains the sources for the d_library foo. To generate HTML documentation for the foo library, define a d_docs target that takes the d_library foo as its dependency:

foo/BUILD:

load("@io_bazel_rules_d//d:d.bzl", "d_library", "d_docs")

d_library(
    name = "foo",
    srcs = [
        "foo.d",
        "bar.d",
        "baz.d",
    ],
)

d_docs(
    name = "foo_docs",
    dep = ":foo",
)

Running bazel build //foo:foo_docs will generate a zip file containing the HTML documentation generated from the source files. See the official D language documentation on the Documentation Generator for more information on the conventions for source documentation.

rules_d's People

Contributors

aaliddell avatar benjaminp avatar buchgr avatar damienmg avatar davidzchen avatar dcarp avatar dslomov avatar jart avatar jo2y avatar kchodorow avatar laurentlb avatar meteorcloudy avatar n8sh avatar philwo avatar ronshapiro avatar vladmos avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rules_d's Issues

Flag --incompatible_load_cc_rules_from_bzl will break rules_d in Bazel 1.2.1

Incompatible flag --incompatible_load_cc_rules_from_bzl will break rules_d once Bazel 1.2.1 is released.

Please see the following CI builds for more information:

Questions? Please file an issue in https://github.com/bazelbuild/continuous-integration

Important: Please do NOT modify the issue title since that might break our tools.

Please move from native to Skylark rules for external git/http repositories

Bazel is planning to move away from native rules for external repositories to Skylark rules, mainly because bundling every version control system in bazel does not scale. As part of this effort, we plan to submit https://bazel-review.googlesource.com/c/bazel/+/55932 soon, which will cause bazel by default to insist that the skylark versions the git and http rules for external repositories be used. This can be disabled by a flag for at least the next 6 months, but we still would appreciate if you could adopt your repository to use the Skylark versions of those rules soon.

A test run of downstream projects with that flag flip in bazel enabled can be found at https://buildkite.com/bazel/bazel-with-downstream-projects-bazel/builds/286

For more background, see

Thanks.

Version referenced in Readme.md yields error because of missing cfg parameter

I applied the rule to WORKSPACE import the D rules, as instructed in the README.md, but building using those rules yields a syntax error that reads:

ERROR: /private/var/tmp/_bazel_jonathanwilbur/a81a9a9aa6841d21bd6bf400ea392816/external/io_bazel_rules_d/d/d.bzl:406:20: cfg parameter is mandatory when executable=True is provided.

I actually forked and I was going to submit a pull request with the correction applied, but it actually looks like the correction is already applied to the source (Line 416 has cfg = "host", as it should); the only problem is that the mirror indicated in the README.md is not up to date with what is in this repository.

Get all tests passing with --all_incompatible_changes under Bazel 0.20.0

rules_d is a dependency for rules_docker, a ruleset that we depend on heavily. We don't use d-lang, but we'd like these rules to pass with --all_incompatible_changes so that we can test that flag on rules_docker.

I tried this myself but rules_d doesn't seem to pass it's tests with Bazel 0.20.0 called via bazel test --incompatible_remove_native_http_archive=false //..., so I couldn't make any progress.

Flag --incompatible_no_implicit_file_export will break rules_d in Bazel 1.2.1

Incompatible flag --incompatible_no_implicit_file_export will break rules_d once Bazel 1.2.1 is released.

Please see the following CI builds for more information:

Questions? Please file an issue in https://github.com/bazelbuild/continuous-integration

Important: Please do NOT modify the issue title since that might break our tools.

Flag --incompatible_no_implicit_file_export will break rules_d in a future Bazel release

Incompatible flag --incompatible_no_implicit_file_export will be enabled by default in a future Bazel release [1], thus breaking rules_d.

The flag is documented here: bazelbuild/bazel#10225

Please check the following CI builds for build and test results:

Never heard of incompatible flags before? We have documentation that explains everything.

If you don't want to receive any future issues for rules_d or if you have any questions,
please file an issue in https://github.com/bazelbuild/continuous-integration

Important: Please do NOT modify the issue title since that might break our tools.

[1] The target release hasn't been determined yet. Our tool will update the issue title once the flag flip has been scheduled.

Flag --incompatible_disable_target_provider_fields will break rules_d in Bazel 1.2.1

Incompatible flag --incompatible_disable_target_provider_fields will break rules_d once Bazel 1.2.1 is released.

Please see the following CI builds for more information:

Questions? Please file an issue in https://github.com/bazelbuild/continuous-integration

Important: Please do NOT modify the issue title since that might break our tools.

Flag --incompatible_disable_depset_items will break rules_d in Bazel 1.2.1

Incompatible flag --incompatible_disable_depset_items will break rules_d once Bazel 1.2.1 is released.

Please see the following CI builds for more information:

Questions? Please file an issue in https://github.com/bazelbuild/continuous-integration

Important: Please do NOT modify the issue title since that might break our tools.

Flag --incompatible_disable_depset_items will break rules_d in a future Bazel release

Incompatible flag --incompatible_disable_depset_items will be enabled by default in a future Bazel release [1], thus breaking rules_d.

The flag is documented here: bazelbuild/bazel#9017

Please check the following CI builds for build and test results:

Never heard of incompatible flags before? We have documentation that explains everything.

If you don't want to receive any future issues for rules_d or if you have any questions,
please file an issue in https://github.com/bazelbuild/continuous-integration

Important: Please do NOT modify the issue title since that might break our tools.

[1] The target release hasn't been determined yet. Our tool will update the issue title once the flag flip has been scheduled.

Get all tests passing with --incompatible_disable_legacy_cc_provider for Bazel 0.25.0

It seems that rules_d will start breaking with the next Bazel release 0.25 because of an incompatible change (bazelbuild/bazel#7036)

ERROR: /Users/buildkite/builds/buildkite-imacpro-2/bazel-downstream-projects/rules_d/examples/hello_lib/BUILD:22:1: in d_source_library rule //examples/hello_lib:native_greeter:
  | Traceback (most recent call last):
  | File "/Users/buildkite/builds/buildkite-imacpro-2/bazel-downstream-projects/rules_d/examples/hello_lib/BUILD", line 22
  | d_source_library(name = 'native_greeter')
  | File "/Users/buildkite/builds/buildkite-imacpro-2/bazel-downstream-projects/rules_d/d/d.bzl", line 356, in _d_source_library_impl
  | fail("d_source_library can only depen...", ...")

https://github.com/bazelbuild/rules_d/blob/master/d/d.bzl is using hasattr(dep, "cc") instead the new provider should be used as described in the link above. For example, to check if the dependency has the provider it should be CcInfo in dep
 

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.