On Fri, 27 Jun 2014 16:07:58 GMT, Maaaks wrote:

You can add it in the depending package (i.e. the final application package that gets built). Versions and debug versions are always propagated to the dependencies to ensure a consistent build.

This is sad that in order to build a library written by developers who prefer Dub, I have to use Dub, too. :)

You don't have to. The VibeCustomMain situation is just based on historical reasons and usually a dub build of the library should suffice to get a binary to link against.

You could also build with custom flags using: 

DFLAGS=-version=VibeCustomMain dub build

This will override the flags of the usual build mode (e.g. -g -debug).

Didn't know about this, thank you!

There is a targetPath setting for specifying where the final binaries are put. Or do you mean that you prefer to put the build results to a whole different location (e.g. ~/my_build_results/libvibe-d.a)?

I don't think that a project file (dub.json) is a good place for writing such machine-specific things. Since dub.json is usually included into VCS repository, it should not have hardcoded paths inside. IMHO, dub command should have arguments for defining such paths on individual developer's machine instead.

Yes, because they are not machine specific for DUB ;) I simply didn't yet encounter the need or request to configure those paths on a machine basis so far, which is the only reason why the current feature set is what it is.

Of course, environment variables are a nice way to do it, too. DFLAGS seems to solve the problem, but is there a similar variable for defining output file?

Currently there isn't, but it could of course be added (as well as a configuration file field). The only thing that would need to be defined in detail is how the main package, the dependencies and the intermediate build files should be affected. Can you give a sketch of how you'd personally organize this, to get a concrete use case example?