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