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

Build should create directories as needed #3326

Closed
catamorphism opened this issue Aug 31, 2012 · 5 comments
Closed

Build should create directories as needed #3326

catamorphism opened this issue Aug 31, 2012 · 5 comments

Comments

@catamorphism
Copy link
Contributor

There comes a time in the life of every Rust developer when they have to blow away various parts of the build directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: cp: x86_64-apple-darwin/stage1/lib/librustrt.dylib: No such file or directory. It would be better if the Makefile would just create all the needed parent directories automatically.

@brson
Copy link
Contributor

brson commented Sep 1, 2012

+1

@pnkfelix
Copy link
Member

pnkfelix commented May 3, 2013

I'm pretty sure I know how to do this. (I think the right tools for the job are some order-only prerequisites in host.mk and target.mk.)

pnkfelix added a commit to pnkfelix/rust that referenced this issue May 3, 2013
This is an attempt to address Issue rust-lang#3326 by adding [*order-only*][1]
prerequsites of each build product on the directory where it is to go.
It is important that the prerequisites be order-only, since the
timestamp on a parent directory is not relevant to whether a product
is out of date; the parent directory merely needs to exist.

(This use case of generating target directories was provided as an
[example][2] of how order-only prequisites are used.)

[1]: http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html

[2]: http://www.kolpackov.net/pipermail/notes/2004-January/000001.html
@pnkfelix
Copy link
Member

pnkfelix commented May 3, 2013

@catamorphism I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: 4dd0fa6) into your repo and give it a spin.

If you don't get around to it, no sweat; it can obviously wait until Monday.

@pnkfelix
Copy link
Member

pnkfelix commented May 3, 2013

@catamorphism argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.

@catamorphism
Copy link
Contributor Author

@pnkfelix Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)

bors added a commit that referenced this issue May 5, 2013
@pnkfelix pnkfelix closed this as completed May 5, 2013
Aatch pushed a commit to Aatch/rust that referenced this issue May 7, 2013
This is an attempt to address Issue rust-lang#3326 by adding [*order-only*][1]
prerequsites of each build product on the directory where it is to go.
It is important that the prerequisites be order-only, since the
timestamp on a parent directory is not relevant to whether a product
is out of date; the parent directory merely needs to exist.

(This use case of generating target directories was provided as an
[example][2] of how order-only prequisites are used.)

[1]: http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html

[2]: http://www.kolpackov.net/pipermail/notes/2004-January/000001.html
pnkfelix referenced this issue in pnkfelix/rust Jul 7, 2013
…stalling.

When building Rust libraries (e.g. librustc, libstd, etc), checks for
and verbosely removes previous build products before invoking rustc.
(Also, when Make variable VERBOSE is defined, it will list all of the
libraries matching the object library's glob after the rustc
invocation has completed.)

When installing Rust libraries, checks for previous libraries in
target install directory, but does not remove them.

The thinking behind these two different modes of operation is that the
installation target, unlike the build tree, is not under the control
of this infrastructure and it is not up to this Makefile to decide if
the previous libraries should be removed.
bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
fix formatting of strings within a macro
RalfJung pushed a commit to RalfJung/rust that referenced this issue Mar 3, 2024
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

No branches or pull requests

3 participants