On Saturday, 12 August 2017 at 06:06:33 UTC, Vladimir Panteleev
On Saturday, 12 August 2017 at 06:02:57 UTC, Vladimir Panteleev
Sounds reasonable, the compiler could check if paths start
with a -J path.
There is a potential ambiguity here:
dmd -Jsomedir test.d
Does the user mean to import "somedir/file.txt" or
"somedir/somedir/file.txt"? Currently the latter is understood.
Simply checking for path prefix would break this case. I guess
this could be done only with absolute paths, but that
introduces an inconsistency with relative paths. I'm not sure
it's worth it, considering it's easy to work around.
What is the inconsistency? Absolute paths are specific and well
defined and so are relatives. Relatives are always relative to J,
are they not?
so, import("somedir/file.txt"); obviously means
If you wanted somedir/file.txt you would do import(`file.txt`).
I see no problem here. With absolute paths, one simply checks if
the absolute base path matches the absolute base path specified
by J. If it matches, then it passes and can be used directly or
removed internally. If not then an error is given.
should pass all pass.
should all fail.
(I'm only using .. for reference, not sure if they should
actually be supported)
It seems quite simple to me
Any relative paths specified by import are prepended with the
path specified by -J. Any absolute paths specified by an import
are first matched to the path -J simply by
if (J_path.length < basepath.length) assert("Import path must be
located in the same path that is specified by -J");
if (basepath[0..J_path.length] != J_path) ditto; // makes sure
absolute path is in the -J path. This is the check that is
missing from dmd.
(this doesn't resolve ..'s, that could be done before and assumes
basepath is an absolute path)