http://d.puremagic.com/issues/show_bug.cgi?id=11330
Vladimir Panteleev <thecybersha...@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #2 from Vladimir Panteleev <thecybersha...@gmail.com> 2013-10-23 18:37:39 EEST --- If the behavior is by design, then the design is broken and needs to be fixed. Reopening. Compilers should not treat source files, which use an extension specifically chosen for the programming language, the same as directories, which can contain anything at all. The current behavior is equivalent to the compiler complaining that there is a file called "b.txt", because its base name is the same as a module/package used in the program. It's not the compiler's business what directories there are in the search path, because they can contain arbitrary files completely unrelated to the task of building the program. The generalized version of my situation is: Let's say you have a program that manages foos. Your program consists of several entry point modules, such as mangle-foos.d and unmangle-foos.d, and a module which contains code that manages foos, foos.d. If you build the program from its source directory, everything is fine. However, if you go to your project directory, which incidentally contains a directory called "foos" containing the data to be managed, and you run "rdmd foosmangler/mangle-foos.d", the build breaks. In my opinion, this is not acceptable. My specific use case is a build tool used to configure, build and deploy a software project. The tool contains a module called "source", which manages the project's source code. If I run it (using rdmd) from the project root, which contains a directory called "source", it breaks. I don't think I need to rename my modules or my source directory to work around this design flaw. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------