Packages and module import

[Jonathan M Davis]

On Monday, March 19, 2018 17:29:10 Russel Winder via Digitalmars-d-learn 
wrote:
> I had assumed that a directory of modules was a package. So for
> example:
>
>   A/a.d
>   A/b.d
>
> were two modules in package A. Especially given there is a module
> statement at the beginning of each module:
>
> A/a.d has  module A.a;
> A/b.d has  module A.b;
>
> Now A.b needs to access something from A.a. I had assumed that the
> import should be fully qualified. So in A.b.d:
>
>   import A.a: thing;
>
> This all works when building the library.

Yes packages are directories and modules are files, but that can be mucked
with on some level by explicitly marking the module with a module path that
doesn't match its directory structure. If you do that, that tends to cause
problems with the compiler finding your module to import, and build tools
like rdmd and dub assume that the module's import path matches the file
structure, but it's unfortunately not actually required, much as
conceptually, that's the idea.

> ldc2 -of=Build/Release/libdvbv5_d.so -shared -defaultlib=phobos2-ldc
> Build/Release/source/libdvbv5_d/linux_dmx.o
> Build/Release/source/libdvbv5_d/dvb_v5_std.o
> Build/Release/source/libdvbv5_d/dvb_frontend.o
> Build/Release/source/libdvbv5_d/dvb_log.o
> Build/Release/source/libdvbv5_d/dvb_demux.o
> Build/Release/source/libdvbv5_d/dvb_fe.o
> Build/Release/source/libdvbv5_d/dvb_file.o
> Build/Release/source/libdvbv5_d/dvb_scan.o
> Build/Release/source/libdvbv5_d/dvb_sat.o -L-ldruntime-ldc
>
>
> However when trying to build the unit-tests:
>
>
> ldc2 -I=source -unittest --main -of=Build/Test/libdvbv5_d
> source/libdvbv5_d/linux_dmx.d source/libdvbv5_d/dvb_v5_std.d
> source/libdvbv5_d/dvb_frontend.d source/libdvbv5_d/dvb_log.d
> source/libdvbv5_d/dvb_demux.d source/libdvbv5_d/dvb_fe.d
> source/libdvbv5_d/dvb_file.d source/libdvbv5_d/dvb_scan.d
> source/libdvbv5_d/dvb_sat.d source/libdvbv5_d/dvb_demux.d(35): Error:
> module linux_dmx from file source/libdvbv5_d/linux_dmx.d must be imported
> with 'import linux_dmx;'
>
>
> Am I just missing something simple?

Well, what's the module statement in linux_dmx.d look like?

For better or worse, while the compiler will infer a module's name from the
file name if you don't give it one, it won't infer the pcakage name. So, if
you have no module declaration in linux_dmx.d, then it's going to be
inferred as being the module linux_dmx with no package. So, that may or may
not be part of your problem.

Based on what you posted, it's not at all clear to me how you're building
this stuff. The first example without -unittest is just dealing with .o
files and not having to deal with imports at all. To know how that's being
dealt with would require the command-line associated with generating the .o
files.

Also, if the import that's being complained about is in a unit test and
isn't imported outside of one, then the problem relating to the import
wouldn't be found when building without -unittest. The same would frequently
be true if it's a template, since often, templates aren't instantiated
outside of unit tests when compiling a library.

- Jonathan M Davis