-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding Contributing file #1
Closed
facebook-github-bot
wants to merge
2
commits into
main
from
automated_fixup_contributing_file_exists
Closed
Adding Contributing file #1
facebook-github-bot
wants to merge
2
commits into
main
from
automated_fixup_contributing_file_exists
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
fbshipit-source-id: 653a22b831d1ed9f0496f75b86ee762cfe95146c
facebook-github-bot
added
the
CLA Signed
This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
label
Sep 25, 2022
facebook-github-bot
force-pushed
the
main
branch
from
September 30, 2022 21:06
5365f34
to
d07d7c1
Compare
facebook-github-bot
pushed a commit
that referenced
this pull request
Dec 6, 2022
Summary: This reverts the Rust parts from D41714656 (fad0244) and implements it better a different way. Advantages of the new approach: 1. No more "falsiness". The default value kicks in only if a value was not passed by the code that instantiated the toolchain, or if `None` was passed. (As far as I can tell there is no way to tell these cases apart, but that seems fine.) Previously we had been doing e.g. `toolchain_info.rustc_flags or []`, which will silently accept a toolchain constructed with inappropriate falsey values like `rustc_flags = False` or `rustc_flags = ""`. 2. A consistent central place for the default values. No more needing to scatter `or []` to every location that a particular attribute is referenced. 3. A central place to observe which attributes have not yet been given a default value, and discuss what those default values should be. Other than #1 above, this diff does not intentionally change any behavior. Reviewed By: zertosh Differential Revision: D41752388 fbshipit-source-id: 47e8b290cc596528a7a3c5b3a68195083725f8bd
facebook-github-bot
pushed a commit
that referenced
this pull request
Jun 15, 2023
Summary: ## This stack This stack is what I have so far for the native `haskell_ghci` buck2 rule implementation. On D44449945 I published an initial RFC with what I had so far, but there were still a lot of things I didn't know. Now, I think I'm much closer to getting to finishing, but there are still a few things I don't know that could be causing the errors that I'm getting... I'll try to aggregate everything in an Help section... My goal now is to 1. Generate scripts that are equivalent (e.g. only differences are in directory paths) 2. Generate all the necessary artifacts (e.g. SOs, scripts), which I'll compare using `tree -lv BUCK_OUT` of buck1 and buck2 output. 3. Run haxlsh and successfully load and run an endpoint. I'm very close to #1. The only thing that's different is that I'm not creating an omnibus SO and I'm passing all the dependencies explicitly. ## This diff As title. Reviewed By: pepeiborra Differential Revision: D46476480 fbshipit-source-id: aa9eea0bd0ed9b65b94156f27adda16fd69afe7e
facebook-github-bot
pushed a commit
that referenced
this pull request
Jun 15, 2023
Summary: The existing `_get_argsfile_output` does two things: 1. creates the argsfile subtarget DefaultInfo provider 2. sets the `by_ext` attribute for use in xcode_data Up the stack, #2 is replaced by the `CompileArgsfiles` record which contains a map of extension to `CompileArgsfile`. Extracting out #1 allows us to restructure the code (later on) to 1. define the argsfile subtarget, DefaultInfo and action only for targets that want it 2. extract it out of compilation so that compilation code is simpler Reviewed By: milend Differential Revision: D46743454 fbshipit-source-id: 31a108410e49fb85851d91334ed598a10731e7d9
facebook-github-bot
pushed a commit
that referenced
this pull request
Dec 19, 2024
…cross all host platforms Summary: ### Motivation My team has a concrete need for buck to generate 100% matching zip files for the same sets of inputs on all host platforms (macOS, Linux, Windows). Current limitations: 1. File order can be different on file system with different case sensitivity. 2. Windows can't write correct posix mode (i.e. permissions) for any entries. Although the entries themselves might fully match, those discrepancies result in different metadata, which results in a different zip file. See D67149264 for an in-depth explanation of the use case that requires this level of determinism. ### Tentative solution #1 In D66386385, I made it so the asset generation rule was only executable from Linux. Paired with buck cross builds, it made so that outputs from macOS and Linux matched, but did not work on Windows [due to some lower level buck problem](https://fb.workplace.com/groups/930797200910874/posts/1548299102494011) (still unresolved). ### Tentative solution #2 In D66404381, I wrote my own Python script to create zip files. I got all the files and metadata to match everywhere, but I could not get around differences in the compression results. Decided not to pursue because compression is important for file size. ### Tentative solution #3 In D67149264, I duplicated and tweaked buck's zip binary. It did work, but IanChilds rightfully pointed out that I'd be making maintenance on those libraries more difficult and that the team is even planning on deleting those, at some point. ### Tentative solution #4 (this diff!) IanChilds advised me to try to fix buck itself to produce consistent results, so this is me giving it a try. Because the root problem could not have been done in a backwards compatible way (the file permissions, specifically; see inlined comment), I decided to use an argument to control whether the zip tool should strive to produce a deterministic output or not, at the expense of some loss of metadata. The changes are simple and backwards compatible, but any feedback on the root problem, idea and execution are welcome. Reviewed By: christolliday Differential Revision: D67301945 fbshipit-source-id: c42ef7a52efd235b43509337913d905bcbaf3782
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
CLA Signed
This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is pull request was created automatically because we noticed your project was missing a Contributing file.
CONTRIBUTING files explain how a developer can contribute to the project - which you should actively encourage.
This PR was crafted with love by Facebook's Open Source Team.