Ability to use do_program without do_build

[rroohhh]

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]

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]

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]

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]

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]

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]

Unfortunate, but understandable.