Allow building termonad instances as standalone project via build script

[inanna-malick]

re:

(These steps are definitely confusing. I would love to figure out a better way to do this. Please submit an issue or PR if you have a good idea about how to fix this.)

I would like to implement XMonad's solution to this problem (a build script stored in the config directory that can be configured to, eg, build a stack project then copy over the executable)

See usage of the buildscript variable in this file for details: https://github.com/xmonad/xmonad/blob/master/src/XMonad/Core.hs#L644-L645

[inanna-malick]

I'm going to go ahead and implement this for my own use, posting here to see if there's support for using this approach

[cdepillabout]

@pkinsky Thanks!

I've actually used the buildscript functionality from XMonad, so I think this would be a nice addition to Termonad.

However, ideally that functionality would be provided in some sort of external library (similar to how Termonad is currently using the dyre library).

Maybe this functionality could be added to dyre? If the maintainer of dyre doesn't want to accept it, maybe you could create a library that wraps dyre and adds support for a buildscript? Then Termonad could just depend on that library? If you added me as a maintainer, I could help maintain it.

(Some name suggestions: even-more-dyre, dyrebs (short of "dynamic reconfiguration with build script support"))

---

I'd say the steps for this are as following:

1. Send a prototype PR adding this functionality to Termonad.
2. Post an issue on the dyre repo asking if the author will consider adding that functionality to dyre.
3. If so, create a PR adding this functionality to dyre. When that gets merged in, create a small PR using that new functionality in Termonad.
4. If the author does not want that functionality in dyre, then we create an external library like even-more-dyre. Send a PR using that new functionality in Termonad.

How does this sound?

[inanna-malick]

my initial thought is that users of this functionality would have to accept losing the dyre auto-reload functionality (monitoring some directory referenced in the buildscript for changes and determining which changes require a reload seems like a hard problem). I was thinking that (at least for myself) I'd be willing to accept manually restarting termonad instances after updating the underlying project, but I'm not sure if that's viable given how people use termonad.

[cdepillabout]

my initial thought is that users of this functionality would have to accept losing the dyre auto-reload functionality (monitoring some directory referenced in the buildscript for changes and determining which changes require a reload seems like a hard problem)

I thought the way that XMonad works is that is always ran the buildscript everytime it started up, and it re-execed itself if the buildscript created a new xmonad binary? I was thinking that the buildscript functionality in Termonad could work the same?

Were you thinking it could be more advanced than that?

[inanna-malick]

I had thought dyre updated every running termonad instance whenever termonad.hs was updated instead of just running it once - that might not be correct.

[cdepillabout]

Let me try to explain a little bit more about what is happening.

When you start Termonad, you normally call the termonad binary you've built with stack or Nix. This binary starts up, and sees if you have a ~/.config/termonad/termonad.hs file. If you don't have this file, then Termonad starts up normally with all the default configuration options.

If you do have ~/.config/termonad/termonad.hs, then Termonad sees if there is a pre-built binary at ~/.cache/termonad/termonad-linux-x86_64. If there is, then Termonad compares the timestamp between ~/.config/termonad/termonad.hs and ~/.cache/termonad/termonad-linux-x86_64. If the timestamp for ~/.cache/termonad/termonad-linux-x86_64 is newer than the timestamp for ~/.config/termonad/termonad.hs, then Termonad just re-execs ~/.cache/termonad/termonad-linux-x86_64.

If the timestamp for ~/.cache/termonad/termonad-linux-x86_64 is older than the timestamp for ~/.config/termonad/termonad.hs (or if ~/.cache/termonad/termonad-linux-x86_64 just doesn't exist), then Termonad uses GHC to recompile ~/.config/termonad/termonad.hs and produce the ~/.cache/termonad/termonad-linux-x86_64 binary. It then re-execs into this new binary (which should have all your configuration options set).

(Actually, almost all of the above logic is actually implemented in the dyre library, not directly in the Termonad source code.)

---

I had thought dyre updated every running termonad instance whenever termonad.hs was updated instead of just running it once

So let me try to explain this.

dyre doesn't update any of the running Termonad instances you have. Termonad only calls into the dyre code-base when you first execute Termonad. All dyre does is recompile the cached termonad-linux-x86_64 binary file and then re-exec into it. After the cached Termonad binary file has been re-execed, Termonad doesn't call into the cached dyre code-base anymore.