Discussion moved from a pull request:

Regarding the app.d problematic, I feel we need to start a more thorough discussion first. As you have probably seen, that "appFile" field would basically be equivalent to adding that file as an "excludedFiles" setting in all non-application configurations, except when --rdmd is used. And --rdmd is still not working when bulding a static or dynamic lib, so that's a related problem ("mainFile"/"rootFile"?). And then there is still the thing with vibe.d's -version=VibeCustomMain that I would like to improve if possible and that may also interact with the descision how to handle the app file. Let's open a forum topic, so it doesn't get lost here.

Exactly any library target would exclude it, the executable target would use it.

I intended to change the look up for the default locations "src/app.d" and "source/app.d" to search it in any specified sourcePath, but I just realized that this is pretty bad, for the not uncommon configuration that there is no source/src folder but instead immediately the D package tree. This is especially common for packages that adhere to the preferred behaviour of just exporting a single package. An example can be found here: 

https://github.com/jacob-carlborg/orange

Putting orange in src, would just add another folder into the hierarchy. The current dub design offers two possibilities to handle this case:

  1. Add the project directory itself as a source directory ("."). The problem is that dub traverses the whole tree it finds in the search for source files, including the .dub folder with all the dependencies. So this approach does not work.
  2. Second add the orange directory as source path and the current directory as an import path. Resulting in an invalid import path: orange/ to be used, but this should not do any real harm.

So as only 2. really works, searching for the app.d file in all source paths, would be bad, because there might be an orange.app file which really is not /the/ app.d we are looking for.

1 could be improved, by having dub ignore files/directories starting with a dot, but I am not sure whether this is enough. Another possibility would be to offer an "includePackages" option. If specified only the listed directories would be copied/linked over to an import directory (as explained in my proposal "D package = package"), which would then be added as import path instead. This would solve both problems of cluttered source directories and packages put in the project's root.

For libraries like vibe, which provide their own main() function. I would suggest adding a libraryMainFile configuration to the package.json. dub will then only link it in, if the application being built has no explicitly defined mainFile.

So we would have:

  • mainFile
  • appFile
  • libraryMainFile

appFile being like mainFile (only link it in when building an application) but it does not specify its own main and dub would scream out loud if no library defines libraryMainFile if an executable is being built (or alternatively rely on the compiler to do this). If mainFile is specified any libraryMainFile would not be linked in.

For an orange-like configuration appFile/mainFile would be mandatory as you would not be able to rely on auto detection of the app/main file.

I also thought of making it somehow possible to disable the auto detection of the app.d file, but as top level modules should really be discouraged I don't see any real reason to do this.

Best regards,
Robert