Am 16.03.2013 10:48, schrieb Robert:> 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.

Number 2 should in fact not add an invalid import path. The import path is supposed to be only added if "source"/"src" was auto-detected as the main source folder. But manually specifying "sourcePaths" really just specifies source paths and doesn't make them import paths.

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.

The whole app.d/<package name>.d file feature is really just supposed to be a short-cut for apps that want to use that application/library split convention. See ddox for an example that doesn't rely on the automatic detection.

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.

Copying around source files sounds like it may create problems, especially with IDE based builds. I think having a few straw import folders is OK, as this kind of structure is not the recommended way and also without DUB the library has the same issue (except if it has a make file that first copies all files to somewhere else). No need to additionally support that kind of structure IMHO.

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.

The problem is that it may need the vibe.d main() even if the application also has an app.d (that only contains a static this). In the old days, rdmd used to resolve that problem purely by tracking the actual dependencies. Now that needs to be done manually, as this is no option for IDE builds. (If all IDEs would agree to use rdmd for building then it would of course be a totally different thing)

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.

I think only one "mainFile" field is needed both, for applications and libraries, and only for "dub --rdmd" so that rdmd has something to start. The appFile/libraryMainFile fields would just be another shortcut for functionality that is already there (using configurations and "excludeFiles") and I don't think this is necessary.

Note that it is one of the new features in 0.9.11 that the auto-detection really just pre-fills one or two configurations ("application" and "library") automatically, depending on which files are found.