RFC - Debug from Packaged Build and removal of SOM_PATH

[chamons]

Right now debugging tom-swifty in the sln does not "do the same thing" as launching it from a package.

I came across it while working on https://github.com/xamarin/maccore/issues/906 and it has bitten me multiple times before. You can not copy paste arbitrary command line arguments into a debug session and expect success.

Today we have a SOM_PATH "hack" I added that kinda does the same thing if you set it right but not really.

This RFC proposes the following:

• Remove SOM_PATH and demote swift-bin-path and swift-lib-path to private options when we move to Mono.Options. Consumers should never ever need to set them. We can leave them around since I assume they are useful to @stephen-hawley else they go completely as well.
• Modify our build to output tom-swifty.exe to copy into a "build\dist" folder.
• Modify the rest of the build to copy components there similar to what make package already does
• Modify make package to literally just bundle up that folder

This way we can always assume our dependent libraries are in sane relative locations and consumers can stop caring about their locations.

Thoughts?

[rolfbjarne]

I agree that anything we can do to make a debug build more like a release/packaged build is the way to go.

[stephen-hawley]

I'm going to inject some history into these two arguments. I put them in because after realizing that I was going to need a custom build of the swift compiler I needed to know where to look for it and had absolutely no idea how SoM was going to be packaged. When in doubt, apply indirection - I made those arguments.

As the primary user of SoM, the following use cases have to be met:

1. Running and debugging unit tests is seamless and painless. Roughly 90% of my time debugging is in this configuration. Why? Because I prefer to be able to take an issue out of the context of an entire library and it's easier to write tests this way.
2. Testing a new build of the reflection code. I try to do this as infrequently as possible because of the time hit, so running a scratch CI build is a non-starter since that can take upwards of 8 hours. Any new build of the compiler needs to integrate in with little or no pilot error on my part.
3. Running and debugging SoM as an application from the IDE on a sample library. I do this rarely and usually to verify "does this library work?" or "which language feature is giving me grief today?". I keep a solid set of command-line arguments around to manage this.
4. Debugging a unit test failure in lldb (usually because of mishandled calling conventions on my part). If I'm here, I'm already grumpy.

I never use SOM_PATH as it makes 2 and 3 unreliable.

I'm all for making the debug build more like a packaged build. Probably the way to do that is to make a separate script to build the swift compiler without --clean, then package it/put it where it needs to be rather than depending on it to live where it was just built. I know that @chamons dug into some of the --skip-build arguments to make iterative builds faster.

tl;dr - I'm all for improvements, but changes that get made to workflow need to:

1. respect a reasonable turnaround on the code/compile/debug cycle
2. eliminate pilot error on changes in libraries or make them either obvious (by putting the compiler build time in your face, say) or really hard (as in if you managed to do this, maybe you should step away from the code for a bit).
3. be intuitive and work well with the IDE.

[rolfbjarne]

I completely agree that we should keep everybody's workflow as good as possible, which is just more fun because everybody's workflow is different 😄

Example: when working on my recent changes I modified the unit tests to not use random paths in /tmp, but instead a stable path, which additionally is not cleaned after the test completes, but the next time a test is executed. This had a couple of benefits:

• I could copy-paste intermediate commands executed by the tests, and they'd still work (because the temporary files were still there).
• I could re-use the same commands after re-running tests (since the location was stable).

Knowing more about the code might have made it easier to be more specific when things failed, but this worked well for me.

A couple of ideas:

1. Running and debugging unit tests is seamless and painless. Roughly 90% of my time debugging is in this configuration. Why? Because I prefer to be able to take an issue out of the context of an entire library and it's easier to write tests this way.

The changes I mentioned above helped me here.

I also noticed that you can just debug the unit test, which is great, but depending on the problem might not be the easiest (it also requires known where to put the breakpoints, which takes a little while to learn).

2. Testing a new build of the reflection code. I try to do this as infrequently as possible because of the time hit, so running a scratch CI build is a non-starter since that can take upwards of 8 hours. Any new build of the compiler needs to integrate in with little or no pilot error on my part.

I'm assuming you run make or some other command that builds your changes: this command should just put the resulting binaries in the right location so they're automatically used everywhere you need them.

3. Running and debugging SoM as an application from the IDE on a sample library. I do this rarely and usually to verify "does this library work?" or "which language feature is giving me grief today?". I keep a solid set of command-line arguments around to manage this.

I like making command lines copy-pastable, so that it's just a matter of pasting the entire thing into VSfM's Run arguments, then execute the project.

Creating command lines with full paths (as opposed to relative paths) help a lot here.

4. Debugging a unit test failure in lldb (usually because of mishandled calling conventions on my part). If I'm here, I'm already grumpy.

Making command lines copy-pastable helps a lot with this too, then you just prepend lldb -- and you're good to go (except if you have to set environment variables, which incidentally is quite frequent in SoM, but here my aforementioned changes come in to play because with stable "temporary" paths you can set environment variables once, and then re-use previous lldb commands even after rerunning the failing test from the IDE).