On 3/17/2014 12:18 PM, Sean Kelly wrote:
So I'd import "core.sys.ucontext.package" if I didn't want a
system-specific module (which should be always)?
No,
import core.sys.ucontext;
Yes, ucontext is a directory. The package.d is a magic file name. This is the
new package design that was incorporated last year, designed specifically to
allow single imports to replaced by packages without affecting user code.
Why this approach and not publishing modules from somewhere into core.sys
on install?
The short answer is I happen to have a fondness for installs that are simple
directory copies that do not modify/add/remove files. I think we are safely
beyond the days that even a few hundred extra files installed on the disk are a
negative.
Even if the non-used platform packages are simply deleted on install, this will
not affect compilation. I think that's still better than modifying files. I've
never trusted installers that edited files.
Besides that, there are other strong reasons for this approach:
1. New platforms can be added without affecting user code.
2. New platforms can be added without touching files for other platforms.
3. User follows simple no-brainer rule when looking at OS documentation:
#include <ucontext.h>
rewrites to:
import core.sys.ucontext;
4. Bugs in particular platform support files can be fixed without concern with
breaking other platforms.
5. Changes in platform support will not touch files for other platforms, greatly
simplifying the QA review process.
6. D installed on Platform X can be mounted as a remote drive and used to
compile for Platform Y.
