www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Compiling an app to a single binary - possible?

reply "Jacek Furmankiewicz" <jacek99 gmail.com> writes:
One of the nice features of Go is that when you compile an app, 
it pulls in ALL the dependencies (i.e. the full SDK + all 
libraries your app depends on) and generates a single binary 
(around 2 MB for a Hello World app).

This is extremely useful for deployment purposes, since it is so 
straightforward to just copy the app to multiple servers without 
having to worry if every one of them has all the required 
dependencies installed / updated, etc.

Does D offer something similar (maybe via some dmd switches)?

For example, If I am creating a vibe.d app, would I need to 
deploy the vibe.d libraries separately with my app on all the 
servers in production?

Thanks
Jacek
Nov 15 2013
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz 
wrote:
 One of the nice features of Go is that when you compile an app, 
 it pulls in ALL the dependencies (i.e. the full SDK + all 
 libraries your app depends on) and generates a single binary 
 (around 2 MB for a Hello World app).
This is the default in D. The main trouble comes when you use outside C libraries (gtk, sdl, curl, etc.), which might need to be installed, and I don't think they can easily be bundled in a single binary, but D apps and libs generally are all statically linked. I don't know for sure about vibe.d specifically though.
Nov 15 2013
prev sibling next sibling parent reply "QAston" <qaston gmail.com> writes:
On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz 
wrote:
 One of the nice features of Go is that when you compile an app, 
 it pulls in ALL the dependencies (i.e. the full SDK + all 
 libraries your app depends on) and generates a single binary 
 (around 2 MB for a Hello World app).

 This is extremely useful for deployment purposes, since it is 
 so straightforward to just copy the app to multiple servers 
 without having to worry if every one of them has all the 
 required dependencies installed / updated, etc.

 Does D offer something similar (maybe via some dmd switches)?

 For example, If I am creating a vibe.d app, would I need to 
 deploy the vibe.d libraries separately with my app on all the 
 servers in production?

 Thanks
 Jacek
D, like many languages compiled to native code (C, C++) supports dynamically loaded libraries (.dll and .so files) as an option. You have an option to use DLLs (in which case you'll have to deploy them) but it's not a requirement - you can build just like in Go as long as you don't use the DDL feature. You should check vibe.d build options whenever it's possible to build it without DLL dependency.
Nov 15 2013
parent "Jacek Furmankiewicz" <jacek99 gmail.com> writes:
Thank you for the quick response, that is great news.

Cheers
Jacek
Nov 15 2013
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 15 November 2013 at 15:27:45 UTC, Jacek Furmankiewicz 
wrote:
 One of the nice features of Go is that when you compile an app, 
 it pulls in ALL the dependencies (i.e. the full SDK + all 
 libraries your app depends on) and generates a single binary 
 (around 2 MB for a Hello World app).

 This is extremely useful for deployment purposes, since it is 
 so straightforward to just copy the app to multiple servers 
 without having to worry if every one of them has all the 
 required dependencies installed / updated, etc.

 Does D offer something similar (maybe via some dmd switches)?

 For example, If I am creating a vibe.d app, would I need to 
 deploy the vibe.d libraries separately with my app on all the 
 servers in production?

 Thanks
 Jacek
Go provides only static linking. D provides both and it is up to developer to decide. Often it is simply a matter of what version of library is installed in the system - static or dynamic one. You can use `ldd` on Linux to check dynamic dependencies for any given binary. On my Arch Linux installation output for simple vibe.d app looks like this: $ ldd ./test linux-vdso.so.1 (0x00007fba8f53b000) libevent_pthreads-2.0.so.5 => /usr/lib/libevent_pthreads-2.0.so.5 (0x00007fba8f11b000) libevent-2.0.so.5 => /usr/lib/libevent-2.0.so.5 (0x00007fba8eed3000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fba8ec66000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fba8e85e000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fba8e640000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fba8e33d000) librt.so.1 => /usr/lib/librt.so.1 (0x00007fba8e135000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fba8dd8a000) /lib64/ld-linux-x86-64.so.2 (0x00007fba8f31e000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fba8db86000) libz.so.1 => /usr/lib/libz.so.1 (0x00007fba8d970000) List may differ between distros / operating systems. Note that you can't "force" static linking if only shared libraries are present in the system and AFAIK Go does no magic here - it will simply fail to compile/link in such situation. tl; dr: yes, if you use static versions of required libraries
Nov 15 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-15 16:27, Jacek Furmankiewicz wrote:
 One of the nice features of Go is that when you compile an app, it pulls
 in ALL the dependencies (i.e. the full SDK + all libraries your app
 depends on) and generates a single binary (around 2 MB for a Hello World
 app).

 This is extremely useful for deployment purposes, since it is so
 straightforward to just copy the app to multiple servers without having
 to worry if every one of them has all the required dependencies
 installed / updated, etc.

 Does D offer something similar (maybe via some dmd switches)?

 For example, If I am creating a vibe.d app, would I need to deploy the
 vibe.d libraries separately with my app on all the servers in production?
Note, if you have any assets you can use the import expression to bundle your assets: http://dlang.org/expression.html#ImportExpression -- /Jacob Carlborg
Nov 16 2013
parent reply "Jacek Furmankiewicz" <jacek99 gmail.com> writes:
It is possible to import an entire folder and subfolders of 
assets? (e.g. static HTML with all of its pieces, i.e. CSS, JSS. 
etc)
Nov 17 2013
next sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Sunday, 17 November 2013 at 18:40:34 UTC, Jacek Furmankiewicz 
wrote:
 It is possible to import an entire folder and subfolders of 
 assets? (e.g. static HTML with all of its pieces, i.e. CSS, 
 JSS. etc)
Are we talking about Vibe.d? Yes, it's possible: http://vibed.org/docs shared static this() { auto router = new URLRouter; router.get("*", serveStaticFiles("./public/")); listenHTTP(new HTTPServerSettings, router); }
Nov 17 2013
parent reply "Jacek Furmankiewicz" <jacek99 gmail.com> writes:
In this case is the content of "./public" compiled directly into 
the executable (let's say the way all web resources are compiled 
into a Java WAR file), or does it have to be a separate folder on 
the filesystem, deployed alongside the main executable?
Nov 17 2013
parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Monday, 18 November 2013 at 00:12:57 UTC, Jacek Furmankiewicz 
wrote:
 In this case is the content of "./public" compiled directly 
 into the executable (let's say the way all web resources are 
 compiled into a Java WAR file), or does it have to be a 
 separate folder on the filesystem, deployed alongside the main 
 executable?
The "./public" folder have to be a separate folder. All Diet templates in "./views" folder compile directly into the executable. See also "The recommended structure for a project is about as follows:" section.
Nov 17 2013
prev sibling parent "Dicebot" <public dicebot.lv> writes:
On Sunday, 17 November 2013 at 18:40:34 UTC, Jacek Furmankiewicz 
wrote:
 It is possible to import an entire folder and subfolders of 
 assets? (e.g. static HTML with all of its pieces, i.e. CSS, 
 JSS. etc)
Theoretically possible but not really expected to and generally does not give you much over simply distributing an archive. I'd even discourage it because it makes impossible to delegate handling of static assets to reverse proxy like nginx (which is likely to do better job at it being specialized tool)
Nov 18 2013