RejectedSoftware Forums

Sign up

How to link against vibe.d without Dub?

All manuals say that vibe.d should be used as a dependency in Dub projects, but Dub seems not very convenient to me for a few reasons. I'm looking for a simple tutorial how to use vibe.d without Dub.

Currently, my program compiles but doesn't link because of multiple definitions of _D4vibe7appmain12__ModuleInfoZ. I have no idea how they could appear. (The library that I'm trying to link against is libvibe-d.a found in my ~/.dub directory.)

Re: How to link against vibe.d without Dub?

On Fri, 27 Jun 2014 14:10:53 GMT, Maaaks wrote:

All manuals say that vibe.d should be used as a dependency in Dub projects, but Dub seems not very convenient to me for a few reasons. I'm looking for a simple tutorial how to use vibe.d without Dub.

It would definitely be interesting to know if there are any things that could be improved here to make DUB more convenient!

Currently, my program compiles but doesn't link because of multiple definitions of _D4vibe7appmain12__ModuleInfoZ. I have no idea how they could appear. (The library that I'm trying to link against is libvibe-d.a found in my ~/.dub directory.)

Currently, -version=VibeCustomMain is required when building the vibe.d library to skip including the default main function of vibe.d (see source/vibe/appmain.d). This will be made the default later this year, after a deprecation phase.

dmd -lib -olibvibe-d.a -Isource -I<path/to/openssl> -I<path/to/libevent> -lssl -lcrypto -levent -levent_threads -version=VibeCustomMain -version=VibeLibeventDriver <all .d files of vibe.d>

Re: How to link against vibe.d without Dub?

For example, I don't like that there seems to be no way to add the -version=VibeCustomMain using command-line switches without modifying dub.json.

For now, I decided to compile vibe.d itself with Dub. I just modified it a little:

    ...
    "dflags": ["-version=VibeCustomMain"]
}

After it, I ran dub build and got libvibe-d.a in the directory.

(This is another reason why I don't like Dub: it always works in current directory. I prefer to have sources in one place and build results in another.)

On Fri, 27 Jun 2014 14:43:17 GMT, Sönke Ludwig wrote:

On Fri, 27 Jun 2014 14:10:53 GMT, Maaaks wrote:

All manuals say that vibe.d should be used as a dependency in Dub projects, but Dub seems not very convenient to me for a few reasons. I'm looking for a simple tutorial how to use vibe.d without Dub.

It would definitely be interesting to know if there are any things that could be improved here to make DUB more convenient!

Currently, my program compiles but doesn't link because of multiple definitions of _D4vibe7appmain12__ModuleInfoZ. I have no idea how they could appear. (The library that I'm trying to link against is libvibe-d.a found in my ~/.dub directory.)

Currently, -version=VibeCustomMain is required when building the vibe.d library to skip including the default main function of vibe.d (see source/vibe/appmain.d). This will be made the default later this year, after a deprecation phase.

dmd -lib -olibvibe-d.a -Isource -I<path/to/openssl> -I<path/to/libevent> -lssl -lcrypto -levent -levent_threads -version=VibeCustomMain -version=VibeLibeventDriver <all .d files of vibe.d>

Re: How to link against vibe.d without Dub?

So, I'm done, thank you. I'll describe my example for those who will read this topic in future.

I'm trying other available build systems for D one after annother. Currently, I build my project with Cook, and I'll use it in my example, but it doesn't matter. The only important thing is that I need to manually specify compiler parameters and linker parameters.

So. This is what I need to pass to the compiler:

-I/path/to/vibe.d/source -I/path/to/openssl-master
-I/path/to/libevent-master -version=VibeCustomMain -version=VibeLibeventDriver

(Since I have all the packages installed with Dub, I can specify paths inside ~/.dub/packages for them.)

This is what I need to pass to the linker:

/path/to/vibe.d/libvibe-d.a -L-ldl -L-levent -L-levent_pthreads -L-lssl -L-lcrypto

Here, libvibe-d.a is the library that I have built in previous post.

For Cook, I run this command in my project's source root:

cook \
-C"-I/path/to/vibe.d/source \
  -I/path/to/openssl-master \
  -I/path/to/libevent-master \
  ...other includes... \
  -version=VibeCustomMain \
  -version=VibeLibeventDriver" \
-L"/d/Sources/vibe.d/libvibe-d.a \
  ...other libraries.a... \
  -L-ldl \
  -L-levent \
  -L-levent_pthreads \
  -L-lssl \
  -L-lcrypto" \
-o MySuperBinary

After compiling all files, this is what Cook runs to link my binary:

dmd -L-rpath -L"." -L-ldl \
  /path/to/vibe.d/libvibe-d.a \
  ...other libraries.a... \
  -L-ldl -L-levent -L-levent_pthreads -L-lssl -L-lcrypto \
  ...all the object files... \
  -ofMySuperBinary

Thanks again!

On Fri, 27 Jun 2014 15:26:20 GMT, Maaaks wrote:

For example, I don't like that there seems to be no way to add the -version=VibeCustomMain using command-line switches without modifying dub.json.

For now, I decided to compile vibe.d itself with Dub. I just modified it a little:

    ...
    "dflags": ["-version=VibeCustomMain"]
}

After it, I ran dub build and got libvibe-d.a in the directory.

(This is another reason why I don't like Dub: it always works in current directory. I prefer to have sources in one place and build results in another.)

On Fri, 27 Jun 2014 14:43:17 GMT, Sönke Ludwig wrote:

On Fri, 27 Jun 2014 14:10:53 GMT, Maaaks wrote:

All manuals say that vibe.d should be used as a dependency in Dub projects, but Dub seems not very convenient to me for a few reasons. I'm looking for a simple tutorial how to use vibe.d without Dub.

It would definitely be interesting to know if there are any things that could be improved here to make DUB more convenient!

Currently, my program compiles but doesn't link because of multiple definitions of _D4vibe7appmain12__ModuleInfoZ. I have no idea how they could appear. (The library that I'm trying to link against is libvibe-d.a found in my ~/.dub directory.)

Currently, -version=VibeCustomMain is required when building the vibe.d library to skip including the default main function of vibe.d (see source/vibe/appmain.d). This will be made the default later this year, after a deprecation phase.

dmd -lib -olibvibe-d.a -Isource -I<path/to/openssl> -I<path/to/libevent> -lssl -lcrypto -levent -levent_threads -version=VibeCustomMain -version=VibeLibeventDriver <all .d files of vibe.d>

Re: How to link against vibe.d without Dub?

On Fri, 27 Jun 2014 15:26:20 GMT, Maaaks wrote:

For example, I don't like that there seems to be no way to add the -version=VibeCustomMain using command-line switches without modifying dub.json.

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.

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).

For now, I decided to compile vibe.d itself with Dub. I just modified it a little:

    ...
    "dflags": ["-version=VibeCustomMain"]
}

After it, I ran dub build and got libvibe-d.a in the directory.

(This is another reason why I don't like Dub: it always works in current directory. I prefer to have sources in one place and build results in another.)

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)?

Re: How to link against vibe.d without Dub?

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 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.

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?

Re: How to link against vibe.d without Dub?

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?

Re: How to link against vibe.d without Dub?

Personally, I like the way that CMake uses: the build is done in the current directory when the script runs, and it doesn't have to be the same directory as the sources directory.

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.

I believe that build path is, hmm, developer-specific. One developer prefers to build project inside the source tree, another one prefers a separate directory, and third one wants to have two different build with different parameters in different directories.

Re: How to link against vibe.d without Dub?

On Sat, 28 Jun 2014 07:42:00 GMT, Maaaks wrote:

Personally, I like the way that CMake uses: the build is done in the current directory when the script runs, and it doesn't have to be the same directory as the sources directory.

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.

I believe that build path is, hmm, developer-specific. One developer prefers to build project inside the source tree, another one prefers a separate directory, and third one wants to have two different build with different parameters in different directories.

Okay, thanks. I've added a ticket for this; #363