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

Ability to use do_program without do_build #350

Closed
rroohhh opened this issue Apr 11, 2020 · 6 comments
Closed

Ability to use do_program without do_build #350

rroohhh opened this issue Apr 11, 2020 · 6 comments
Labels

Comments

@rroohhh
Copy link
Contributor

rroohhh commented Apr 11, 2020

It would be nice to be able to use do_program=True without rebuilding everything (for example to quickly reflash a board after power cycling it).

@whitequark
Copy link
Member

There are two issues with implementing this improvement.

  1. This would break the (admittedly loosely typed and not necessarily very good) interface of Platform.build.
  2. Right now, you can't program outdated build artifacts by accident, but with this change, it'd be pretty easy to do so.

Have you considered using toolchain_program directly?

@rroohhh
Copy link
Contributor Author

rroohhh commented Apr 11, 2020

There are two issues with implementing this improvement.

  1. This would break the (admittedly loosely typed and not necessarily very good) interface of Platform.build.
  2. Right now, you can't program outdated build artifacts by accident, but with this change, it'd be pretty easy to do so.

Do you think having do_build=False and do_program=True as arguments would not provide enough indication that this can potentially program outdated build artifacts?

Have you considered using toolchain_program directly?

I am not sure how I could use toolchain_program directly without hardcoding internal information about BuildProducts / LocalBuildProducts into my program.

@whitequark
Copy link
Member

Do you think having do_build=False and do_program=True as arguments would not provide enough indication that this can potentially program outdated build artifacts?

In my experience, this is a common enough issue that it's better to be as explicit as possible with operations that may result in outdated build artifacts. In principle, I would be more comfortable using a dependency tracking system (something like Make, except Make doesn't work well on Windows, so we can't use that).

But let's say I accept that it is enough indication. (1) is still an issue.

I am not sure how I could use toolchain_program directly without hardcoding internal information about BuildProducts / LocalBuildProducts into my program.

Platform.build is intended solely as a shortcut for running the code inside it as the most common case. It is not an abstraction. You are free to directly run prepare, execute_local and toolchain_program.

@rroohhh
Copy link
Contributor Author

rroohhh commented Apr 11, 2020

Do you think having do_build=False and do_program=True as arguments would not provide enough indication that this can potentially program outdated build artifacts?

In my experience, this is a common enough issue that it's better to be as explicit as possible with operations that may result in outdated build artifacts. In principle, I would be more comfortable using a dependency tracking system (something like Make, except Make doesn't work well on Windows, so we can't use that).

But let's say I accept that it is enough indication. (1) is still an issue.

Yes I guess what I actually want is nmigen skipping rebuilding the design if it did not change.
Do you want me to change the title / the first comment to reflect that, or maybe open a new issue for that?

I am not sure how I could use toolchain_program directly without hardcoding internal information about BuildProducts / LocalBuildProducts into my program.

Platform.build is intended solely as a shortcut for running the code inside it as the most common case. It is not an abstraction. You are free to directly run prepare, execute_local and toolchain_program.

Oh I totally missed the run_script option of execute_local, that would of course work.

@whitequark
Copy link
Member

Yes I guess what I actually want is nmigen skipping rebuilding the design if it did not change.
Do you want me to change the title / the first comment to reflect that, or maybe open a new issue for that?

I would classify this as out of scope for nMigen at the moment. There are two main issues:

  1. A reliable system that rebuilds the artifacts would take into account not just the (already self-contained, thankfully) build directory, but also the versions of dependencies. This is not so important with vendor tools that update a few times a year at most, but very much so with the FOSS toolchain that updates very often. nMigen embeds its own version into generated files, but the rest still needs work, and it's not clear that there is an off-the-shelf solution here.
  2. Such a system should also come without additional native depenencies to ensure nMigen works well on Windows.

@rroohhh
Copy link
Contributor Author

rroohhh commented Apr 11, 2020

Unfortunate, but understandable.

@rroohhh rroohhh closed this as completed Apr 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants