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

Use external gyp #8850

Closed
lucab opened this issue Aug 29, 2013 · 3 comments
Closed

Use external gyp #8850

lucab opened this issue Aug 29, 2013 · 3 comments

Comments

@lucab
Copy link
Contributor

lucab commented Aug 29, 2013

The latest libuv master has gained a new dependency on gyp in order to generate its Makefile. We are currently git-cloning it at build time in order to have it.

It would be good to have a switch to just use a system-wide gyp.

PS. note that this is also means that next stable source tarball is going to have dependency on git. Maybe it would be better to use a git submodule also for gyp?

@huonw
Copy link
Member

huonw commented Aug 29, 2013

Doesn't the source tarball already depend on git for LLVM & libuv? (I could easily be wrong; I have no idea about this.)

@lucab
Copy link
Contributor Author

lucab commented Aug 29, 2013

The submodules are fetched by make dist and bundled in the tar.gz. The idea is that (if you want/need) you don't have to rely on external resources or even the network to build from the tar archive. This also helps improving deterministic builds.

@alexcrichton
Copy link
Member

I agree that when we re-update libuv (reverting the revert), that a submodule is the best way to go here.

bors added a commit that referenced this issue Sep 6, 2013
This is a reopening of the libuv-upgrade part of #8645. Hopefully this won't
cause random segfaults all over the place. The windows regression in testing
should also be fixed (it shouldn't build the whole compiler twice).

A notable difference from before is that gyp is now a git submodule instead of
always git-cloned at make time. This allows bundling for releases more easily.

Closes #8850
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 4, 2022
Only return `DefId`s to `Fn`-like definitions in `clippy_utils::fn_def_id`

Fixes rust-lang#8850

in `returns.rs` `tcx.fn_sig` is called on the result of `fn_def_id`, which panics if the def is a `const`/`static`/etc rather than a functions definition

https://github.com/rust-lang/rust-clippy/blob/bc4d39e5fea64970dded1e6d2132d41435c0ef24/clippy_lints/src/returns.rs#L294-L303

changelog: Fix ICE due to callable `static`/`const`s
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants