Drasil: Add drasil-build to SubPackages Wiki

[samm82]

The drasil-build subpackage isn't in the wiki for subpackages, so it should be updated.

EDIT: Created in #1212 and is responsible for "build system languages and renderers"

TODO

• [x] Remove --force-dirty from page

[samm82]

@smiths Do you think that this wiki page should be kept up-to-date, since the subpackage split is old news, and Gabe (I think) fixed how the packages are built? I'm happy to update it, I'm just not sure how useful/relevant it would be to do so.

[smiths]

Yes, I definitely think the wiki page should be kept up to date. We want to reach a day whether people can contribute to, or at least appreciate, our project from outside McMaster. This will require up to date documentation. I'm glad to see that you created this issue. :smile:

[samm82]

@smiths and/or @Mornix if you want to look over my additions to the wiki to see if I'm missing anything, then this issue can be closed.

[Mornix]

The note about requiring --force-dirty being out of date is correct. It shouldn't be needed anymore.

My only nitpick is in the dependency graph the arrow directions seem backwards. If drasil-build depends on drasil-lang, I'd expect the arrow to be the "depends-on" relationship and have the arrowhead be at the drasil-lang end.

[samm82]

Should I remove the --force-dirty completely or keep it for traceability?

And yeah - I originally made the chart last summer before taking 2AA4, so I just made it how I thought (and still think) naturally about dependencies, that the arrow points in the same direction as exports. I realize that the standard is that the arrows mean dependencies the other way, and remember being very confused in class about this. 😂 I put the note there last summer specifying the arrow direction to be explicit, but I'll change it so we're all on the same page. Thanks!

[Mornix]

I don't think --force-dirty is needed at all any more. I believe Stack is able to track all of that and perform selective recompilation even without a version bump with the current build setup.

[samm82]

So what should the new workflow be for bumping version numbers? It just seems like a hassle, especially when it's not strictly-speaking necessary anymore. I feel like we still should, but I'm not sure when.

[samm82]

Removed - this issue can be closed whenever @smiths decides 😁

[Mornix]

Version numbers should (ideally) still be bumped on a package whenever its public interface (something listed in the re-export files) changes. And anytime a package uses the updated function, it should be bumped to the latest version. Additionally the consumer of the new function _should_ increase its version number as a consequence. In practice, I usually try to do a single set of version bumps and updates to public functions per pull request to keep things tidy if I remember.

@JacquesCarette Correct me if my version number update "flow" disagrees with what you prefer.

[JacquesCarette]

Agree, that is indeed how things should work.

[smiths]

The tasks associated with this issue have been completed, so we can close this issue.