A fast build system that encourages the creation of small, reusable modules over a variety of platforms and languages.

Overview

logo

Buck

Buck is a build tool. To see what Buck can do for you, check out the documentation at http://buck.build/.

Build Status

Installation

Since Buck is used to build Buck, the initial build process involves 2 phases:

1. Clone the Buck repository and bootstrap it with ant:
git clone --depth 1 https://github.com/facebook/buck.git
cd buck
ant

You must be using Java 8 or 11 for this to compile successfully. If you see compilation errors from ant, check your JAVA_HOME is pointing at one of these versions.

2. Use bootstrapped version of Buck to build Buck:
./bin/buck build --show-output buck
# output will contain something like
# //programs:buck buck-out/gen/programs/buck.pex
buck-out/gen/programs/buck.pex --help
Prebuilt buck binaries

Pre-built binaries of buck for any buck sha can be downloaded from https://jitpack.io/com/github/facebook/buck/<sha>/buck-<sha>.pex. The very first time a version of buck is requested, it is built via jitpack. As a result, it could take a few minutes for this initial binary to become available. Every subsequent request will just serve the built artifact directly. This functionality is available for any fork of buck as well, so you can fetch https://jitpack.io/com/github/<github-user-or-org>/buck/<sha>/buck-<sha>.pex

For buck binaries built for JDK 11, modify end of the url to buck-<sha>-java11.pex.

Feature Deprecation

Buck tries to move fast with respect to its internals. However, for user facing features (build rules, command line interface, etc), the Buck team tries to have a graceful deprecation process. Note that this generally applies only to documented functionality, or functionality that is less documented, but appears to be in wide use. That process is:

  • An issue is opened on Github suggesting what will be deprecated, and when it will be removed. For larger features that are deprecated, there may be a period when the default is the new setting, and the old behavior may only be used with a configuration change.
  • A change is submitted to Buck that puts the old behavior behind a configuration flag and sets the default to the old behavior. These flags can be found at https://buck.build/concept/buckconfig.html#incompatible.
  • For larger features, a change eventually is put in place that sets the default to the new behavior. e.g. when Skylark becomes the default build file parser.
  • When the removal date is reached, a change is submitted to remove the feature. At this point, the configuration value will still parse, but will not be used by Buck internally.

License

Apache License 2.0

Issues
  • Add support for error prone as native compiler option

    Add support for error prone as native compiler option

    Fixes #994.

    Summary: http://errorprone.info is a static analysis tool for Java that catches common programming mistakes at compile-time. With this change it can be permanenty or instantly activated as default compiler. Moreover, java_library rule is extended as well.

    The configuration option: java.error_prone_javac is considered to be experimental and is not documented.

    Test Plan:

    1. Permanently activate error prone: add this line to .buckconfig:
       [java]
         error_prone_javac = true
    
    1. Instantly activate error prone:
      $ buck build --config java.error_prone_javac=true <rule>
    
    1. Activate error prone per rule base:
    java_library(
        name = 'foo',
        error_prone_javac = True,
        [...]
    
    CLA Signed GH Review: needs-revision Import Started 
    opened by davido 90
  • Kotlin in-memory compiler support.

    Kotlin in-memory compiler support.

    Changes to support #1037, #956, and #395.

    CLA Signed GH Review: review-needed Import Started 
    opened by brettwooldridge 61
  • RFC: Introduce build rules for building GWT applications.

    RFC: Introduce build rules for building GWT applications.

    I'm looking into adding build rules for building GWT applications. I'm curious what folks think the arguments to the rules should look like.

    • Do we need a special gwt_library() rule, or can we just use java_library()? My intuition is that if you use JSNI in your Java code, then you need to classify that as a gwt_library().
    • How do you deal with dependencies that have dual implementations: one for the JRE and one for JavaScript? For example, you may have a subgraph of dependencies that transitively depend on Guava. Then at the top, you have a gwt_binary() target and a java_binary() target? How do you ensure that the gwt_binary() pulls in guava-gwt-17.0.jar while the java_binary() pulls in guava-17.0.jar? One option is to have parallel versions of each subgraph, but that seems messy.
    • How can we design gwt_binary() (or this whole system of rules) so that it is easy to run the GWT app in developer mode? Ideally, a developer should not have to run buck build after every code modification in order to reload the GWT app. The existing edit-refresh-test cycle needs to be preserved.
    opened by bolinfest 58
  • [IntelliJ] Handle resources_root in project generation

    [IntelliJ] Handle resources_root in project generation

    IntelliJ project generation right now doesn't generate resource folders for Java code, instead relying directly on the generation of source folders. This results in resources being put in the wrong places if resources_root is different from the Java src_roots option. This change introduces a new type of IjFolder (JavaResourceFolder) which tracks resources_root if it is set and sets the relativeOutputPath of the IntelliJ folders to try and handle this correctly.

    Note that it probably can't be fully handled correctly if there are source files and resource files mixed in the same directories, because IntelliJ's granularity only goes to the directory level, while buck can set them at the file level.

    I'm not entirely sure if this is the best approach to handling this, would appreciate any suggestions

    CLA Signed GH Review: accepted Import Started 
    opened by zhan-xiong 54
  • Filtering platform specific source files

    Filtering platform specific source files

    This PR fixes #1701

    Known issue:

    srcs=['.'] will crash on go_binary rules but not on go_library. The crash happens before GoCompile.getBuildSteps gets called. Temporary workaround is to use srcs=glob(["*.go"]). The filtering still works.

    CLA Signed Import Started 
    opened by linzhp 53
  • Update manifest merger

    Update manifest merger

    This switches to ManifestMerger2 implementation and fixes https://github.com/facebook/buck/issues/299

    Majority of this PR is updating aosp to 25.2.0 version of the tools.

    The only interesting change is in GenerateManifestStep.java.

    For the sake of not maintaining two versions of aosp, this PR replaces old ManifestMerger with ManifestMerger2. Having both is possible (we could take ManifestMerger from tools 24.x.x, the last version that shipped with it) but if the new merger works for everyone, probably best to just go with that.

    CLA Signed GH Review: accepted Import Started 
    opened by marcinkwiatkowski 52
  • Parallelize swift compilation by compiling file individually

    Parallelize swift compilation by compiling file individually

    This PR is one of the effort to rework the incremental build support https://github.com/facebook/buck/pull/907.

    Instead of compiling all swift files in a target in one shot, we create build rule for each of the file so that we can compile them in parallel, therefore speed up the compilation process, especially useful for a target with a lot of swift files.

    CLA Signed GH Review: needs-revision 
    opened by nguyentruongtho 46
  • Cross-cell: Fix file system mismatch in classpath resolution

    Cross-cell: Fix file system mismatch in classpath resolution

    Rule can be provided from different cell and thus output file name must be relocated according to cell root. Change all the methods on JavaLibraryClasspathProvider that take Optional outputJar to take Optional outputJar instead.

    SourcePaths are much safer because they encapsulate the project filesystem. That way we know they can always be resolved correctly.

    Closes #545

    TEST PLAN:

    Clone JGit with this patch: [1]. Clone Gerrit Code Review with this patch: [2]. Replace JGit cell during Gerrit build, with:

    $ buck build --config repositories.jgit=../jgit gerrit

    Observe, that without this diff, the classpath contains invalid entries: non relocated jgit output file. This diff relocates it to jgit cell.

    [1] https://git.eclipse.org/r/61938 [2] https://gerrit-review.googlesource.com/73000

    CLA Signed GH Review: accepted 
    opened by davido 44
  • Decouple proguard application logic from package type

    Decouple proguard application logic from package type

    Decoupling proguard application from the package type as there are cases when one would want to apply proguard on a debug build for debugging purposes with a different configuration than release

    CLA Signed GH Review: accepted Import Started 
    opened by kageiit 43
  • Populate Styleable entries correctly in R.java generated by MiniAapt

    Populate Styleable entries correctly in R.java generated by MiniAapt

    • Styleable entries array now contain right int values equal to its correspondding attr values. Android attributes are still given random values since R.java is not available at MergeAndroidResourcesStep for libraries.
    • Set R idValues of a parent library equal to it’s dependent libraries idValue.
    CLA Signed GH Review: accepted Import Started 
    opened by raviagarwal7 43
  • make_pex.py failed on Building in WSL:Ubuntu

    make_pex.py failed on Building in WSL:Ubuntu

    Build the project by using ./bin/buck build --show-output buck it throw error common.py should handle the permission but for some reason there is something is not right
    Python 3.8.5 buck version 87135f8e0de092a6be12736c5254c0c125a2b238

    `Building: finished in 4.1 sec (100%) 202/1853 jobs, 77 updated Total time: 4.1 sec Command failed with exit code 1.

    command: [/usr/bin/python3, /mnt/c/buck/ant-out/buck-modules-resources/python/make_pex.py, --python-shebang=/usr/bin/env python3, --python, /usr/bin/python3, --python-version, CPython 3.8, --entry-point, programs.gen_buck_info, buck-out/gen/ce9b6f2e/programs/gen_buck_info.pex]

    stderr: Traceback (most recent call last): File "/mnt/c/buck/ant-out/buck-modules-resources/python/make_pex.py", line 193, in sys.exit(main()) File "/mnt/c/buck/ant-out/buck-modules-resources/python/make_pex.py", line 190, in main pex_builder.build(output) File "/mnt/c/buck/third-party/py/pex/pex/pex_builder.py", line 418, in build chmod_plus_x(filename) File "/mnt/c/buck/third-party/py/pex/pex/common.py", line 153, in chmod_plus_x os.chmod(path, path_mode) PermissionError: [Errno 1] Operation not permitted: 'buck-out/gen/ce9b6f2e/programs/gen_buck_info.pex'

    When running <pex>.
    When building rule //programs:gen_buck_info.`
    
    opened by mh884 1
  • genrule macros cannot target flavor of buck invocation

    genrule macros cannot target flavor of buck invocation

    It appears that a genrule which uses the $(location <target>) macro has no way of getting the location of the output of the specified target for the flavor which was used to invoke buck in the first place.

    In other words, if I invoke buck with:

    1. buck build //MyApp:MyApp#iphoneos-arm64 or
    2. buck build //MyApp:MyApp#iphonesimulator-x86_64

    I have no way of creating a genrule which when it does a $(location <target>) macro expansion targets the #iphoneos-arm64 flavor in case 1 and targets the #iphonesimulator-x86_64 flavor in case 2.

    opened by jstaahl 1
  • brew install --HEAD buck not working

    brew install --HEAD buck not working

    image

    ➜ ~ arch -arm64 brew install --HEAD buck ==> Installing buck from facebook/fb ==> Downloading https://www.apache.org/dyn/closer.lua?path=ant/binaries/apache-a Already downloaded: /Users/Mac/Library/Caches/Homebrew/downloads/3dcf25c6574b35db948c4d796dfcb09055e5c212ae4ab5b874ade9d9735ac158--apache-ant-1.9.15-bin.tar.bz2 Error: [email protected]: no bottle available! You can try to install from source with: brew install --build-from-source [email protected] Please note building from source is unsupported. You will encounter build failures with some formulae. If you experience any issues please create pull requests instead of asking for help on Homebrew's GitHub, Twitter or any other official channels.

    image

    opened by wulongwang 1
  • GA: build_openjdk

    GA: build_openjdk

    GitHub Actions: Run build_openjdk job on Ubuntu and MacOS. I find GitHub Actions faster and easy to setup compared to Circle CI. Please see https://github.com/dulmandakh/buck/actions/runs/884121899

    And I would like to migrate more jobs once this merged.

    CLA Signed 
    opened by dulmandakh 2
  • Error when running ./bin/buck build --show-output buck

    Error when running ./bin/buck build --show-output buck

    When running ./bin/buck build --show-output buck

    Shivs-MacBook-Pro:buck shivkumarmalik$ ./bin/buck build --show-output buck Warning: JAVA_HOME is set to "/Library/Java/JavaVirtualMachines/jdk-11.0.11.jdk/Contents/Home", which looks like a Java 11 path, but Buck requires Java 15. Ignoring JAVA_HOME. Set BUCK_RESPECT_JAVA_HOME to 1 to disable this behavior. Building: finished in 6.2 sec (100%) 375/1851 jobs, 91 updated Total time: 6.2 sec Command failed with exit code 1.

    stderr: : error: Source option 6 is no longer supported. Use 7 or later.

    : error: Target option 6 is no longer supported. Use 7 or later.

    Errors: 2. Warnings: 0.

    When running <source_only_abi>.
    When building rule //src/com/facebook/buck/jvm/java:fat-jar-main#source-only-abi.
    

    Even brew install buck is failing Shivs-MacBook-Pro:buck shivkumarmalik$ brew install buck Updating Homebrew... ==> Auto-updated Homebrew! Updated 1 tap (homebrew/core). ==> New Formulae [email protected] ==> Updated Formulae Updated 77 formulae.

    ==> Installing buck from facebook/fb ==> Downloading https://github.com/facebook/buck/releases/download/v2021.01.12.01/buck-2021.01.12.01.yosemite.bottle.tar.gz Already downloaded: /Users/shivkumarmalik/Library/Caches/Homebrew/downloads/2ab45ceec4daf7c5124e199210a577ad8db53a56c80456dd5f9847b020baa0ae--buck-2021.01.12.01.yosemite.bottle.tar.gz ==> Pouring buck-2021.01.12.01.yosemite.bottle.tar.gz cp: /usr/local/Cellar/buck/./2021.01.12.01_1/bin/buck: Permission denied Error: Failure while executing; cp -pR /private/tmp/d20210523-15358-1az8yo2/buck/. /usr/local/Cellar/buck exited with 1. Here's the output: cp: /usr/local/Cellar/buck/./2021.01.12.01_1/bin/buck: Permission denied

    opened by skm1907 1
  • Apple library submodule

    Apple library submodule

    I'm trying to build Realm, but it's modulemap has submodules:

    ` module Realm { umbrella header "Realm.h"

    export *
    module * { export * }
    
    explicit module Private {
        header "RLMAccessor.h"
        header "RLMApp_Private.h"
        header "RLMArray_Private.h"
        header "RLMCollection_Private.h"
        header "RLMListBase.h"
        header "RLMObject_Private.h"
        header "RLMObjectBase_Dynamic.h"
        header "RLMObjectBase_Private.h"
        header "RLMObjectSchema_Private.h"
        header "RLMObjectStore.h"
        header "RLMOptionalBase.h"
        header "RLMProperty_Private.h"
        header "RLMRealm_Private.h"
        header "RLMRealmConfiguration_Private.h"
        header "RLMResults_Private.h"
        header "RLMSchema_Private.h"
        header "RLMSyncConfiguration_Private.h"
        header "RLMSyncUtil_Private.h"
        header "RLMUser_Private.h"
    }
    
    explicit module Dynamic {
        header "RLMRealm_Dynamic.h"
        header "RLMObjectBase_Dynamic.h"
    }
    

    } `

    How do I specify these submodules in apple_library rule?

    opened by rafabertholdo 0
  • Original test class name is lost when running a JUnit test suite

    Original test class name is lost when running a JUnit test suite

    When running buck test with the --xml argument, the resulting XML file contains the name of the test class that was run in a <test> element and the name of each individual method within that class in child <testresult> elements. However, when running a JUnit test suite, the name of the test class is replaced with the name of the test suite in the <test> element. This can make it difficult (/impossible) to differentiate tests that are in different classes but have the same method name.

    Expected behaviour: The original test class name should be recorded when using a test suite Actual behaviour: The original test class name is replaced by the name of the test suite Steps to reproduce: Run buck test --xml on a JUnit test suite

    For example, given a contrived example with the following test classes / methods:

    • TestCase1 => test1(), test2(), test3()
    • TestCase2 => test1(), test2(), test3()
    • TestCase3 => test1(), test2(), test3()
    • TestCase4 => testA()

    ... running these as a suite might generate an XML such as the one attached. As you can see, the report generated by buck makes it impossible to test which version of test1(), test2() and test3() failed. It isn't even clear if they all came from the same test class, although one might assume that they did given that they are together.

    The original JUnit XML that was parsed in order to create the output.xml file does contain the both the suite name and the class name, so I don't see any particular reason why the class name shouldn't make its way across to the buck-generated file also?

    However, I'm not sure what the ultimate desired behaviour should be when using a test suite - logically I would expect it to mimic the JUnit output of nesting the test classes under the test suite, but I don't know if this structure lends itself well to the other types of tests that buck supports. The alternatives would be to either:

    1. drop the suite information completely and just parse the JUnit XML as if it was the individual tests that had run (this would be my preference) or
    2. use an approach similar to the JUnit XML where the original class name is included as an extra attribute on the tag (less desirable to me as that's a change to the XML schema)

    I have knocked together a change that implements option 1 and I'm happy to raise this as a PR if there is agreement that using a suite should work in this way. Alternatively, happy to look at making a different change if there's some consensus that it should work in a different way.

    opened by swarren12 1
  • Incorrect class-abi for Kotlin 1.5.0

    Incorrect class-abi for Kotlin 1.5.0

    Why? Buck can not read Kotlin 1.5.0 metadata. KotlinClassMetadata.read() returns null trying to parse 1.5.0 source file. -KotlinMetadataReader.java

    Reproduce:

    1. Update kotlin-compiler to 1.5.0
    2. Update kotlin-stdlib to 1.5.0 [optional]
    3. Run StubJarTest#kotlinClassWithInlineMethod

    How to fix:

    1. Add assertion to metadata reader
    2. Update kotlinx-metadata-jvm : 0.1.0 -> 0.3.0
    opened by rybalkinsd 3
  • The behaviour of `buck test` using both `--include` and `--exclude` is unintuitive

    The behaviour of `buck test` using both `--include` and `--exclude` is unintuitive

    The documentation around the --include and --exclude flags of buck test are a bit confusing and doesn't seem to match up with how it works in practice. I'm not sure if the documentation is out of date and the behaviour is correct or whether this is a genuine bug in the behaviour of these flags.

    Expected behaviour: Using --include and --exclude in conjunction applies both filters Actual behaviour: Using --include and --exclude in conjunction ignores --exclude Steps to reproduce: Run buck test --all --include fast --exclude fast+unstable

    The documentation around buck test provides the following example of using the --include and --exclude flags:

    --include Test labels to run with this test. Labels are a way to group together tests of a particular type and run them together. For example, a developer could mark all tests that run in less than 100 milliseconds with the fast label, and then use:

    buck test --all --include fast

    to run only fast tests. See java_test() for more details. Use multiple arguments to match any label, and + to match a set of labels. For example to match all the fast tests that are either stable or trustworthy, and aren't unstable:

    … --include fast+stable fast+trustworthy --exclude fast+unstable

    The later example implies that both --include and --exclude can be used together, although the example itself is questionable as (presumably) the included labels (fast+stable, fast+trustworthy) will never overlap with the excluded label (fast+unstable)?

    For example, given four build rules:

    java_test(
    	name = 'test1',
    	srcs = [ 'javatest/tests/FastStableTest.java' ],
    	deps = [ ':junit' ],
    	labels = [ 'fast', 'stable' ],
    	visibility = [ 'PUBLIC' ],
    )
    
    java_test(
    	name = 'test2',
    	srcs = [ 'javatest/tests/FastTrustworthyTest.java' ],
    	deps = [ ':junit' ],
    	labels = [ 'fast', 'trustworthy' ],
    	visibility = [ 'PUBLIC' ],
    )
    
    java_test(
    	name = 'test3',
    	srcs = [ 'javatest/tests/FastUnstableTest.java' ],
    	deps = [ ':junit' ],
    	labels = [ 'fast', 'unstable' ],
    	visibility = [ 'PUBLIC' ],
    )
    
    java_test(
    	name = 'test4',
    	srcs = [ 'javatest/tests/SlowTest.java' ],
    	deps = [ ':junit' ],
    	labels = [ 'slow' ],
    	visibility = [ 'PUBLIC' ],
    )
    

    ... running buck test --all would run all four:

    $ buck test --all
    RESULTS FOR ALL TESTS
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastStableTest
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastTrustworthyTest
    FAIL    <100ms  0 Passed   0 Skipped   1 Failed   tests.FastUnstableTest
    PASS      1.0s  1 Passed   0 Skipped   0 Failed   tests.SlowTest
    
    TESTS FAILED: 1 FAILURE
    Failed target: //:test3
    FAIL tests.FastUnstableTest
    

    ... and likewise running buck test --all --include 'fast' runs the three fast tests:

    $ buck test --all --include 'fast'
    RESULTS FOR ALL TESTS
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastStableTest
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastTrustworthyTest
    FAIL    <100ms  0 Passed   0 Skipped   1 Failed   tests.FastUnstableTest
    
    TESTS FAILED: 1 FAILURE
    Failed target: //:test3
    FAIL tests.FastUnstableTest
    

    ... and running buck test --all --exclude 'unstable' runs the three non-failing tests:

    $ buck test --all --exclude 'unstable'
    RESULTS FOR ALL TESTS
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastStableTest
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastTrustworthyTest
    PASS      1.0s  1 Passed   0 Skipped   0 Failed   tests.SlowTest
    TESTS PASSED
    

    ... but running buck test --all --include 'fast' --exclude 'unstable' runs all three fast tests rather than just two (as I would expect):

    $ buck test --all --include 'fast' --exclude 'unstable'
    RESULTS FOR ALL TESTS
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastStableTest
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastTrustworthyTest
    FAIL    <100ms  0 Passed   0 Skipped   1 Failed   tests.FastUnstableTest
    
    TESTS FAILED: 1 FAILURE
    Failed target: //:test3
    FAIL tests.FastUnstableTest
    

    Weirdly, the order of the --include and --exclude flags appears to have an effect, because swapping them around produces a different result:

     $ buck test --all --exclude 'unstable' --include 'fast'
    RESULTS FOR ALL TESTS
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastStableTest
    PASS    <100ms  1 Passed   0 Skipped   0 Failed   tests.FastTrustworthyTest
    TESTS PASSED
    

    This is all very confusing and not intuitive. In a small example project it might not seem particularly relevant, but in a large code base it would be convenient to have a broad category of tests (e.g. 'fast') and then a subset of those that may not need to be run every time (e.g. 'intermittent') and having to specify an extra label to do the inverse (e.g. 'fast+reliable') rather than just --excludeing the subset (e.g. 'fast+intermittent') tests seems cumbersome?

    (example: https://github.com/swarren12/buck-test-labels-example)

    opened by swarren12 0
  • Using a `python_library` build rule as a dependency to another build rule does not behave consistently

    Using a `python_library` build rule as a dependency to another build rule does not behave consistently

    The behaviour of python_library when used as a dependency to another build rule is currently inconsistent (or at least, the documentation doesn't make it clear what should and should not work).

    • Expected behaviour: python_library targets should be usable as dependencies to other build rules
    • Actual behaviour: python_library targets are usable as dependencies to some targets (e.g. python_binary) but not others (e.g. genrule)
    • Steps to reproduce: add a python_library target as a src of a genrule.

    The documentation provides an example of using a python_library as a dependency to a python_binary rule, implying that there is some output of a python_library that can be referenced by other targets:

    python_binary(
      name = 'tailer',
      main_module = 'tailer',
      deps = [
        ':tailerutils',
      ],
    )
    
    python_library(
      name = 'tailerutils',
      # The main module, tailer.py, is specified here.
      # (Separated out from the glob pattern for clarity.)
      srcs = glob(['tailer.py', '*.py']),
    )
    

    Building the example works fine, although you can see that the //:tailerutils target does indeed produce no output:

    $ buck build --show-outputs //:tailer
    //:tailer buck-out/gen/tailer.pex
    $ buck build --show-outputs //:tailerutils
    //:tailerutils
    $ ./buck-out/gen/tailer.pex          
    hello world
    

    However, trying to include //:tailerutils in other targets (using a trivial genrule as an example) doesn't seem to work, e.g.:

    genrule(
      name = 'lstailer',
      cmd = 'tree * > $OUT',
      srcs = [
        ':tailerutils',
      ],
      out = 'lstailer.txt'
    )
    

    Attempting to build this target gives the following error:

    $ buck build --show-outputs //:lstailer
    No known output for: //:tailerutils
        When amending unnamedSources.
        When amending srcs.
        When amending buildableForRuleKey.
        When building rule //:lstailer.
    

    In contrast, depending on the //:tailer target works as expected (which makes sense given that this does appear to have a well-defined output):

    genrule(
      name = 'lstailer',
      cmd = 'tree * > $OUT',
      srcs = [
        ':tailer',
      ],
      out = 'lstailer.txt'
    )
    
    $ buck build --show-outputs //:lstailer 
    //:lstailer buck-out/gen/lstailer/lstailer.txt
    $ cat buck-out/gen/lstailer/lstailer.txt
    buck-out
    └── gen
        └── tailer.pex -> /home/example/buck-out/gen/tailer.pex
    
    1 directory, 1 file
    

    I would expect that, given the source files of the python_library target are made available to the python_binary target, this behaviour should be consistent across all build rules?

    I wondered if there was a workaround to this by using some kind of string expansion macro that could be used in the genrule, e.g. srcs = [ '$(query_targets "inputs(//:tailerutils)"), but it appears that this also isn't made available.

    (example: https://github.com/swarren12/buck-python-library-example/).

    opened by swarren12 0
Releases(v2021.01.12.01)
Owner
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Facebook
Adaptable, fast automation for all

Gradle is a build tool with a focus on build automation and support for multi-language development. If you are building, testing, publishing, and depl

Gradle 12.3k Sep 14, 2021
A Maven plugin which fixes Scala dependencies incompatible with Java 9+

scala-suffix Maven Plugin A Maven plugin which fixes Scala dependencies incompatible with Java 9+. A bit of context First of all, you need this plugin

Maciej Gorywoda 6 Jul 8, 2021
Packages your JAR, assets and a JVM for distribution on Windows, Linux and Mac OS X

About Packages your JAR, assets and a JVM for distribution on Windows, Linux and macOS, adding a native executable file to make it appear like a nativ

libgdx 2.2k Sep 11, 2021
Docker container orchestration platform

Helios Status: Bug-fix only This project was created when there were no open source container orchestration frameworks. Since the advent of Kubernetes

Spotify 2.1k Sep 19, 2021
IzPack - Source Code

IzPack IzPack is a widely used tool for packaging applications on the Java platform as cross-platform installers. License IzPack is published under th

IzPack 270 Sep 4, 2021
Documentation and issues of https://jitpack.io

JitPack.io JitPack is a novel package repository for JVM and Android projects. It builds Git projects on demand and provides you with ready-to-use art

JitPack 2.1k Sep 12, 2021
A gradle plugin based on ANTLR to generate UML diagrams from kotlin source code.

A gradle plugin based on ANTLR to generate UML diagrams from kotlin source code.

Alex Porter 9 Aug 29, 2021
Apache Maven core

Apache Maven Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can man

The Apache Software Foundation 2.8k Sep 17, 2021
Dead-Simple Packaging and Deployment for JVM Apps

Capsule Dead-Simple Packaging and Deployment for JVM Applications Capsule is a packaging and deployment tool for JVM applications. A capsule is a sing

Parallel Universe 1.1k Aug 26, 2021