1) In the source file
2) In the makefile
3) In both
It seems to me that the only sane option is (1) with a project-wide or system-wide set of "roots". Why is anyone in favor of (2) or (3)?
In general, modules should not import their dependencies, but have them provided to them by their common parent. See Newspeak's module system as an example.
Alternatively, infer the interface and type check that in the composing module.
As the other commenter wrote, the answer is that modules can never "import" concrete modules, only interfaces. And that means some extra effort, though having type-inference assist with the construction of that module should help. Definitely something that needs figuring out.
IMHO, explicit composition is something we really need to figure out in general, and it should solve the weird mix of linguistic and extra-linguistic mechanisms we have now.
If X needs one of (Y1, Y2, ...) to run - I could understand some kind of external configuration.
It's especially useful for frameworks and game engines. Kinda strange to edit sourcecode of tomcat or unreal engine to configure it to use particular regexp implementation.
So, currently we have four ways to resolve dependencies:
1. Specific at compile time (import in source file via compiler)
2. Unspecific at compile time (via build system)
3. Specific at run time (shared library via OS)
4. Unspecific at compile time (via plugin system)
I am dreaming of a programming system that takes advantage of the modern developer workstations which are very powerful and thus can support more sophisticated design and build tools than a text editor and a make. (IDEs provide only an incremental improvement on top of these.)
The only counterexample that I can think of is LabVIEW, which is pretty successful with (or rather, despite) its visual editing. (Its main selling point is device compatibility, AFAIK.)
So if you have a design for a visual (or, more generally, "beyond-text") programming system in your head that's any good, please let it out. I'd like to see it. (And until then, I'm sticking to vim.)
That said, nothing prevents anyone from having (admittedly rather vague) ideas about using a computer as something more than a glorified typewriter.
I know, it's hard - people could not imagine a car looking different from a horseless carriage back in the day...
(Speaking of the "dream", it is something along the lines of modern environments for Smalltalk. When you model a system, you do not necessarily want to be repeatedly going through the rigid edit/compile/debug cycle; the environment could in theory give you more "immediate" experience modeling the system you are trying to develop.)