Am 17.03.2013 21:56, schrieb Robert:>

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?

Yes, so if a custom "configurations" section or an own "sourcePaths" definition are specified, they will override the default choices. See package_.d line 101 ff. It first searches for all standard folder names and adds them, then parses the package.json file to let the user override the settings, and finally generates default configurations if none have been specified.

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 don't see how the static/dynamic libraries would solve that. If vibe.d would be compiled as a dynamic library, the linker should not consider it's main function at all and if compiled as a static library it should produce conflicting definition errors as in the source library case. It would be great if the linker could somehow be employed for this, but I don't see how yet.

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?

I think the approach with handling modules and HTML documentation and also the version statements is a good idea. But I think we shouldn't rely on that information for the build, if just because we may not be able to continually generate this information for branches if there are many active projects. Avoiding dependencies to rebuild also sounds like a low-priority issue, so as long as we don't introduce a road block for that somewhere, I think we can get to that once everything else is settled. Let's first get the build semantics right (...and some important stuff that has nothing to do with semantics at all).

Also, when implementing this, I would make the whole thing a small separate build server that is controlled by a simple REST interface from the start, so that it can be a separate process with different user rights and on a different server (or multiple servers).

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?

The question I have in mind is how official it will become to build with rdmd. With voices that IDEs should also use the external build tool to build a project and other voices that always want to build with --rdmd it sounds like we should possibly actually provide rdmd support for all kinds of projects and we could maybe even go back and base everything on it...

Then of course it still has some severe bugs because of dmd's lacking dependency output (string imports and local imports are not tracked).

...actually I think the whole rdmd functionality should be part of DMD itself, as it could collect the needed dependencies during compilation instead of doing a separate compilation pass just for that, but even if DMD already does everything else (docs, coverage, profiling) this idea seems to produce no consent.