fails with incompatible $HOME/.profile

[ktye]

very cool project (and impressive blog)!

clicking activate.bat fails for me, if i have a custom $HOME/.profile, for an existing msys2 setup.

In my case the problem is paths (msys2 /c/.../ vs busybox /.../)
But the general question is:
Should your self-contained system read configs at all?

[skeeto]

Thanks for the kind words, ktye, and for pointing this out. I hadn't considered this conflict mostly because my own normal shell config is .bash_profile rather than .profile. This is tricky since my intention is not for this to be a self-contained system-in-a-box such that users work within some virtual environment. My intention is more the opposite. It's only the tools that are packaged together into a kit that can be moved around and discarded at will. Since it's disposable, nothing important — let alone a home directory — should go under w64devkit/. Otherwise the kit's tools are supposed to integrate naturally with the rest of the system. Users may choose to toss the bin/ directory in their $PATH and access parts of the environment without going through activate.bat, which is merely a convenience entrypoint. Case in point, busybox-w32 understands and uses Windows drives and paths which allows it to interface more directly with native Windows software. Contrast with Cygwin, msys2, and WSL which each use a custom unix-like virtual path scheme. This has advantages, especially with portability, but doesn't integrate so well with tools from outside of their ecosystem. For example, CMake irritatingly insists on absolute paths for everything, and so CMake as packaged for msys2, Cygwin, or WSL cannot reliably invoke native Windows tools. Or vice versa. Similarly, by default Cygwin, msys2, and WSL provide a specialized home directories under their respective installations. (So then I suppose you've configured your profile environment to have HOME set to the msys2 home directory? Normally w64devkit won't look there.) I imagine this was in large part because of Microsoft's insane, and thankfully now abandoned, idea to name the profile directory "Documents and Settings" spaces and all, which wouldn't play so well with lots of scripts. But even besides that, isolation is still necessary because parts of the environment are virtual. So I really do want the default activate.bat to load $HOME/.profile. I don't intend for users to set aside a special home directory just for w64devkit — though they are mostly free to do so if they like, outside of some shortcomings with busybox-w32 — but rather treat their user profile directory as their home.