build: link star and binary executable in workdir

[VincentVanlaer]

No description provided.

[Debraheem]

if the goal is to restore the old interface entirely, then the clean and mk commands should be restored in virtually every directory except a couple of the module directories, including all the test cases in star, astero, and binary, and potentially some of the old */test directories located inside star and other modules.

[Debraheem]

We probably need to update the changelog as well, since it indicates these commands were removed.

[VincentVanlaer]

Fair, someone might want to start from a test case as workdir

[warrickball]

Personally I don't see the value in restoring ./clean and ./mk, though I do see the value of restoring ./star. Some users re-use the executable in multiple work directories, where they might not duplicate the build infrastructure, but I'd only expect to run make and make clean in places where I can build MESA.

I'll back down if there's user feedback in favour of restoring ./clean and ./mk though. I'm probably more tolerant of these build system changes than most users.

[VincentVanlaer]

I think it is more a matter of not breaking scripts which call mk and clean. While there is no expectation that MESA is backwards compatible, I am favourable towards not breaking when it is not needed.

I think in that sense both the location of star and the scripts is similar in that regard. It requires you to make modifications your own helper scripts. If we can avoided that, or at least provide a cleaner transition story, that would be good. There will also be a large body of tutorials which use all of this.

[warrickball]

Fair enough. If we intend to nudge towards make and make clean, do we perhaps want to add a message to ./mk and ./clean along the lines of

This script is included for backwards compatibility. You can run make clean directly instead and may wish to do so in case this script is removed in a future MESA release.

That isn't a well-thought out proposal of the message but just something to demonstrate the idea.

I'm equally happy to not bother with such a message, though.

[Debraheem]

I tend to agree with Warrick in the sense that we don't need the clean and mk scripts anymore, but i also think it's fine to keep them for backwards compatibility, for now.

[wmwolf]

I'm also pretty okay with cleaning up some of these legacy scripts in favor of a more industry-standard approach, even if it breaks some existing scripts. To ease the transition, though, here are a couple [potentially bad] ideas:

1. Keep all scripts alongside modern interface, but add annoying deprecation warnings indicating that in a future release, they'll be removed. Then in another release or two, pull the trigger and delete them.
2. Provide some shell script in the scripts directory that can be used to update older scripts that users created to use the newer interface. That might be harder than it sounds, though... replacing ./clean with make clean is easy enough, but if we are calling scripts in other directories, then it gets harder (../other_dir/./clean maps to pushd ../other_dir && make clean && popd).