Ya'll need true packages
FeepingCreature
feepingcreature at gmail.com
Fri Oct 29 06:59:31 UTC 2021
On Tuesday, 19 October 2021 at 04:03:38 UTC, Mathias LANG wrote:
> I was looking at a few packages recently, and noticed a
> bothering trend: Single-module libraries ending up at the top
> level.
>
> Why is it bothering ? Well, here's a little puzzle: Does the
> following code compile?
> ```D
> import std.stdio;
>
> void main ()
> {
> writeln(foo.stringof);
> }
> ```
>
> The answer is "maybe". In most case, it will not. However, if
> the file this resides in is named `foo.d`, it will compile.
> Because the module name accounts for an identifier that can be
> addressed in the scope of the module (and other modules that
> import it).
This is ultimately because D modules just reuse the notion of
import paths from C. I had to find a better way in my language in
order to handle self-rebuilds, where there's name collisions
between compiler runtime and compiled runtime packages, but the
same approach would also solve the issue in D, so let me outline
it.
Basically, we replace import paths (`-I~/.dub/packages/bla/src`)
with package paths:
```
-Pbla:~/.dub/packages/bla/src
```
As you can see, each package is named. This allows us to
explicitly specify which packages a package can see and access:
```
-Pmain:src:bla,bla2
```
As it walks imports, the compiler tracks each module's package.
When evaluating an import statement, only files in the current
package or a direct dependency of the current package are
considered.
Thus, your 'foo' problem will only happen if you directly depend
on package "foo" in your dub.json.
This approach is fully backwards compatible with include paths.
It also allows other funky things, such as per-package settings
(-i, -deps, -g, -debug etc) which solves a whole host of problems
with dub. For instance, a static library can safely be used, even
if the main program's source is being built with different flags.
More information about the Digitalmars-d
mailing list