Skip to content
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

Conversation

facebook-github-bot
Copy link
Contributor

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.

fbshipit-source-id: 653a22b831d1ed9f0496f75b86ee762cfe95146c
@facebook-github-bot 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 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant