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.
Ah ok, great! Sorry I missed that.
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.
Makes sense. What if I have my source files in src/source is it possible to use them as source directory but not as import directory? Is there a way to override the default? Should we probably drop a default setting if it is configured explicitly?
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)
I see (also thanks for explaining how vibe used to work). This means if we handle dependencies by simply creating libraries static/dynamic and linking to them (so the linker will only use vibe's main if the user has not defined one) or alternatively relying on rdmd, the vibe's main problem is solved? rdmd builds would simply only work if there is an app.d in src/source, so dub could simply provide an error message if --rdmd is used but no app.d is found, sounds ok to me.
I am currently thinking about handling dependencies by simply building a static/dynamic library for each package and link to it. I think this would be the most straight forward and efficient approach, but as you already might have noticed in the "conflict" discussion, I am very much in favour for making things as robust as possible. I want things to just work for the user and not having to handle subtle errors or unexpected behaviour. That is why I would put some work in having dub and the registry do what it can to make sure that what you are linking to, matches the definitions the application sees at compile time.
This means, at the compilation of the application the same -version and -debug arguments should be used as they were used when building the library. (Is there something else to be considered?) Of course not every -version/-debug argument really affects the library, this is why I would like to implement the following in the registry:
- When a new version of a package is released, the registry will download it and extract it.
- The modules in the package will be recorded in the database as belonging to the package
- HTML documentation is generated
- The code gets searched for any version() and debug() statements, those will be listed online so the user knows what debugging/version options the library has. In addition dub can use this information to know what version/debug statements are actually going to affect the build, so it only needs to provide a new build of a library on actually relevant changed settings.
For retrieving the version/debug information I intend using one of the D parsers, that people have already written. It might not be 100% reliable, because of string mixins, but as the use of version() is seldom enough, its use within string mixins should be even more rare. A simple statement in a dub/registry tutorial/documentation/guideline that those would not be handled correctly should be enough.
What do you think? What are your plans?
For the problem of this thread (and vibe's main): Simply rely on linker or rdmd -> No need to specify the main/app file. For the rdmd build we simply assume it is app.d, if not, you don't use the --rdmd build?
Best regards,
Robert