On Thu, 23 Dec 2010 12:54:42 -0800
Jonathan M Davis <jmdavisp...@gmx.com> wrote:
> What you're trying to do is pretty abnormal really, as far as your average
> module goes. I assume that you're writing a test app which needs access to
> the
> main body of code and are trying to find a way to point it to that code
> without
> mixing the two.
What is then abnormal in having test modules in their own dir? And indeed they
need to import the module(s) they're supposed to test (and possibly ordinary
and test data from another dir). AFAIK, this is very ordinary lib structuration
for the sake of clarity. Dunno.
> The normal way to deal with that would be -I. The same goes for
> C++ actually. Not to mention, you probably don't want your tests to rely on
> where they are on disk in comparison to the rest of your code. If you later
> want
> to change where you put your test code, it could be a big hassle to have to
> go
> change all of your imports. Just use -I. It makes your test code properly
> portable and is really the intended way to do the sort of thing that you're
> trying to do.
Hem, I do not find a hassle to change one a few import once if ever I move a
test module in the dir tree. But I find very unconvenient to have different
compile/link command lines for every module just because of the lack of an
importing syntax, requiring the use of -I. Instead of a command-line option, I
would prefere to write it down once and for in the module itself. Maybe we
could have something like
pathlevel 2;
saying that (when an imported module is not found) the indicated path is to be
understood as relative to 2 dir levels higher (which would probably be the root
of the lib).
By the way, when I write "import data.foo", the language actually searches and
inside /data (relative to the current module's dir) and find foo.d there. (Even
if the module is not explicitely named at all.) So, there is still an implicite
or default relationship between dir tree structure and module denomination. Or
do I misinterpret your words?
Denis
-- -- -- -- -- -- --
vit esse estrany ☣
spir.wikidot.com
