Hello,

I working on a small program, which I'd like to make publicly available and easy to distribute,install and use.

I'm trying to figure out the best way to distribute it.
Writing D code is a lot of fun, but it looks like preparing and packaging it is not so much...

So far, I'm stuck at:

1.
Packaging for source-based distribution (ie a "tarball"):
I couldn't find a working autotools template (only few old discussions),
and so far it seems the best way is writing my own makefile (which I have).

My concern is that the parameters are so different between dmd/gdc/ldc that I basically force the users to choose one.

I'm also not sure whether it will work on windows or not (I'm developing on linux). For windows users, would a custom,hand-written make file just work?

Although "rdmd" is terrific, I would really prefer not to require it (since it is 'dmd' specific and not free in the FOSS sense).


2.
How complicated it for potential users of the program to install a D compiler?

Based on my humble experience:
dmd: fine, as long as the downloadable binary version works. I tested only on multiple debians and ubuntus. But it's not free, and it requires root privileges.
gdc: only source code available, compiling is a bit tricky. After compilation, it works.
ldc: the pre-compiled version doesn't work on old Ubuntu (10.4) or new Debian (7). The source code version is messy to compile and I stopped after couple of tries.

So, it seems, that if a random person (not unix expert) wants to compiler my program, he/she will not have an easy time doing so.


3.
Distributing Binaries:
Since I already assume source distribution is not friendly, I consider also making the pre-compiled binaries available for download.
But it looks like it's only possible to compile dynamically-linked binaries.

The only leads I've found are two old bugs:
http://d.puremagic.com/issues/show_bug.cgi?id=6952
http://d.puremagic.com/issues/show_bug.cgi?id=4376

And I couldn't find any better solution (on dlang.org or google).
---

All the above, makes me somewhat reconsider whether D is an optimal choice: even if my program is useful in theory, it's of no use if very few people can actually run it.

Are there any suggestions how to deal with these issues ?

Thanks,
 -gordon

On Tuesday, 25 February 2014 at 01:21:03 UTC, Assaf Gordon wrote:
> 1.
> Packaging for source-based distribution (ie a "tarball"):
> I couldn't find a working autotools template (only few old discussions),
> and so far it seems the best way is writing my own makefile (which I have).
>
> My concern is that the parameters are so different between dmd/gdc/ldc that I basically force the users to choose one.

GDC and LDC have gdmd/ldmd respectively, which wrap DMD-style command line arguments over the GCC/Clang-style arguments that `gdc` and `ldc` accept.

> I'm also not sure whether it will work on windows or not (I'm developing on linux). For windows users, would a custom,hand-written make file just work?

That depends almost entirely on the shell commands used in the target recipes. Also, it's easy to create reliance on a certain flavour of `make`, such as by using GNU-make-specific features; it's not a big problem though because GNU make is relatively easy to get on Windows through MinGW.

> Although "rdmd" is terrific, I would really prefer not to require it (since it is 'dmd' specific and not free in the FOSS sense).

`rdmd` itself should be free software, and supports `gdmd` and `ldmd` through the --compiler flag.

DMD itself is indeed not entirely free software.

> 2.
> How complicated it for potential users of the program to install a D compiler?
>
> Based on my humble experience:
> dmd: fine, as long as the downloadable binary version works. I tested only on multiple debians and ubuntus. But it's not free, and it requires root privileges.
> gdc: only source code available, compiling is a bit tricky. After compilation, it works.
> ldc: the pre-compiled version doesn't work on old Ubuntu (10.4) or new Debian (7). The source code version is messy to compile and I stopped after couple of tries.
>
> So, it seems, that if a random person (not unix expert) wants to compiler my program, he/she will not have an easy time doing so.

Maybe we should have a generic Linux binary package that statically links all dependencies, which would then be usable on a wide variety of Linux systems without requiring root privileges.

But are there really no packages of `gdc` and `ldc` in various package repositories? I haven't used D on Linux in a while, but I find that hard to believe.

> 3.
> Distributing Binaries:
> Since I already assume source distribution is not friendly, I consider also making the pre-compiled binaries available for download.
> But it looks like it's only possible to compile dynamically-linked binaries.

I'm pretty sure the default still uses static linking, even with recent Linux releases? Either way, I'm sure there's a way to get the old behaviour. Dynamic linking of the runtime is a relatively recent ability.

You can use hack in Makefile to find out whether the current platform is Windows or not. Check for SystemRoot environment variable in this way:

ifdef SystemRoot
	SYSTEM=Windows
else ifdef SYSTEMROOT
	SYSTEM=Windows
else
	SYSTEM=Other
endif

In non-Windows case use Unix uname command to determine current platform (Linux, Darwin, etc).

If you don't want to force user to install MSys or Cygwin, use Windows-shell commands instead Unix ones. Example:

ifeq ($(SYSTEM), Windows)
	RM=cmd //C del
	CP=cmd //C copy
else
	RM=rm -f
	CP=cp
endif

So you can achieve some flexibility here.
Sometimes developers write separate makefiles named windows.mak and posix.mak, but those ones still can share common parts via include directive.


Also you can write small build-system for your project in D itself. Derelict uses this approach. It also allows to ensure that D compiler was installed and works properly.

On Tuesday, 25 February 2014 at 01:21:03 UTC, Assaf Gordon wrote:
> dmd: fine, as long as the downloadable binary version works. I tested only on multiple debians and ubuntus. But it's not free, and it requires root privileges.

dmd does not require root. The install instructions about copying stuff into /etc and such are ridiculously overcomplicated - dmd actually just works* if you run it straight out of the zip as any regular user in any location.

* if the binary works on your distro, sometimes there's a version mismatch forcing you to build it yourself. That's not a hard thing to do either, the source is included and you can just make it as a regular user, but an extra step doesn't do 'just works'.

> But it looks like it's only possible to compile dynamically-linked binaries.

This is more of a Linux problem than a D one. But most D programs will work normally, dynamically linking the C library *usually* works and that's all a D app really needs.

If you want more binary compatibility btw I'd say stick to building Windows exes, they almost always just work, even on Linux with wine.

On 2014-02-25 00:50:55 +0000, Assaf Gordon said:

> Hello,
> 
> I working on a small program, which I'd like to make publicly available and easy to distribute,install and use.
> 
> I'm trying to figure out the best way to distribute it.
> Writing D code is a lot of fun, but it looks like preparing and packaging it is not so much...
> 
> So far, I'm stuck at:
> 
> 1.
> Packaging for source-based distribution (ie a "tarball"):
> I couldn't find a working autotools template (only few old discussions),
> and so far it seems the best way is writing my own makefile (which I have).
> 
> My concern is that the parameters are so different between dmd/gdc/ldc that I basically force the users to choose one.
> 
> I'm also not sure whether it will work on windows or not (I'm developing on linux). For windows users, would a custom,hand-written make file just work?
> 
> Although "rdmd" is terrific, I would really prefer not to require it (since it is 'dmd' specific and not free in the FOSS sense).
> 
> 
> 2.
> How complicated it for potential users of the program to install a D compiler?
> 
> Based on my humble experience:
> dmd: fine, as long as the downloadable binary version works. I tested only on multiple debians and ubuntus. But it's not free, and it requires root privileges.
> gdc: only source code available, compiling is a bit tricky. After compilation, it works.
> ldc: the pre-compiled version doesn't work on old Ubuntu (10.4) or new Debian (7). The source code version is messy to compile and I stopped after couple of tries.
> 
> So, it seems, that if a random person (not unix expert) wants to compiler my program, he/she will not have an easy time doing so.
> 
> 
> 3.
> Distributing Binaries:
> Since I already assume source distribution is not friendly, I consider also making the pre-compiled binaries available for download.
> But it looks like it's only possible to compile dynamically-linked binaries.
> 
> The only leads I've found are two old bugs:
> http://d.puremagic.com/issues/show_bug.cgi?id=6952
> http://d.puremagic.com/issues/show_bug.cgi?id=4376
> 
> And I couldn't find any better solution (on dlang.org or google).
> ---
> 
> All the above, makes me somewhat reconsider whether D is an optimal choice: even if my program is useful in theory, it's of no use if very few people can actually run it.
> 
> Are there any suggestions how to deal with these issues ?
> 
> Thanks,
>   -gordon


Have you looked at having dub be your autotool?

On Tue, Feb 25, 2014 at 7:16 AM, Shammah Chancellor <anonymous@coward.com>wrote:

> Have you looked at having dub be your autotool?
>

The complaint is about difficulties with installation of a compiler and rdmd, and you suggest to bring in yet another dependency?

My experience is the same as described, I keep a VM on Amazon EC2 with CentOS 5, which contains installed LDC2, just so that the compiled binaries run on any Linux x86_64 machine no matter how old glibc version is.

On Tuesday, 25 February 2014 at 01:21:03 UTC, Assaf Gordon wrote:
> Hello,
>
> I working on a small program, which I'd like to make publicly available and easy to distribute,install and use.

If you want to do distribution to developers, dub[1] is the way to go.

If you want to distribute to desktop users, binary packages is the way to go. The issues with static linking are related to C libraries. If you develop in Linux you generally don't statically link. All your D code is statically linked, work has been done to support dynamic linking with Phobos, but for now that isn't default.

1. http://code.dlang.org/

On Tuesday, 25 February 2014 at 01:21:03 UTC, Assaf Gordon wrote:
> I couldn't find a working autotools template (only few old discussions),
> and so far it seems the best way is writing my own makefile (which I have).

https://github.com/bioinfornatics/MakefileForD

For building dub and/or rdmd are de-facto standard for any D developers. You should just start from source tarball and proceed from there to finding maintainers in specific distributives, possibly being the one for distro or two. Then conform packaging rules there.

Single Linux-wide binary distribution is mostly a myth and dmd shows it by its own.

On 02/25/2014 12:09 AM, Artem Tarasov wrote:
> On Tue, Feb 25, 2014 at 7:16 AM, Shammah Chancellor
> <anonymous@coward.com <mailto:anonymous@coward.com>> wrote:
>> Have you looked at having dub be your autotool?
> The complaint is about difficulties with installation of a compiler
> and rdmd, and you suggest to bring in yet another dependency?
>
> My experience is the same as described, I keep a VM on Amazon EC2
> with CentOS 5, which contains installed LDC2, just so that the
> compiled binaries run on any Linux x86_64 machine no matter how old
> glibc version is.
>

Thanks!
I was beginning to think I'm alone in this problem :)

I'm getting the impression that D is either windows-focused (which is a mostly homogenous system everywhere and easy to work with), or unix-experts/developers-focused (where people feel naturally comfortable with downloading and compiling and fidgeting with programs).

-----

To address some of the other responses:

On 02/24/2014 09:09 PM, Adam D. Ruppe wrote:> On Tuesday, 25 February 2014 at 01:21:03 UTC, Assaf Gordon wrote:
>
> dmd does not require root. The install instructions about copying
> stuff into /etc and such are ridiculously overcomplicated - dmd
> actually just works* if you run it straight out of the zip as any
> regular user in any location.
>

From a non-expert unix POV -
Either you download and install the package (deb/rpm) which is easy but requires root,
or you download and compile the sources from the source zip - which is complicated.
We can argue about what "complicated" means, obviously the members of this forums are mostly experts, so they don't think that compiling from source is tricky.
But if you download the zip, and try to look at it from a novice's POV:
The README.txt is not helpful.
There's no "configure" or "CMakefile" or "Makefile" - which are the most common ways to "just make it work" for open source projects.
Going into "src", there's no Makefile, and the "readme.txt" is again not helpful (talks about the license, not about the installation).
If you're have some experience, you can guess that "posix.mak" is the relevant file, and indeed "make -f posix.mak" builds dmd correctly.
Then you have to repeat the same for "./src/dmd", "./src/druntime" and "./src/phobos" - and then what?
update $PATH, $LD_LIBRARY_PATH ? would that be enough ?
All these might be easy for you - but not for a casual Linux user (which is my intended target audience).

-----

On 02/25/2014 12:48 AM, Jesse Phillips wrote:
>
> If you want to distribute to desktop users, binary packages is the
> way to go. The issues with static linking are related to C
> libraries. If you develop in Linux you generally don't statically
> link.

You "generally don't statically link" because you can:
1. Readily and easily compile from source code on the local machine, or
2. Have binary distribution that perfectly matches your system (in the case of debs/rpms from an official repository).

With D - I have none of these.
And when distribution just an executable to run on an unknown linux machine, the best way is a statically linked binary.

> All your D code is statically linked, work has been done to support
> dynamic linking with Phobos, but for now that isn't default.

But I'm not asking for dynamic linking... I'm asking for static linking that works...

----

On 02/25/2014 08:13 AM, Dicebot wrote:
> For building dub and/or rdmd are de-facto standard for any D
> developers. You should just start from source tarball and proceed
> from there to finding maintainers in specific distributives, possibly
> being the one for distro or two. Then conform packaging rules there.
>

My target audience is not D developers - it is unix casual users (not even developers).
I want to make it the easiest for them to use my program.
If it's requires more than the standard "configure && make && make install" (or the cmake equivalent), then many of them will not do it.

> Single Linux-wide binary distribution is mostly a myth and dmd shows
> it by its own.

Not sure what the "myth" is - but a statically-linked binaries work well (if your program is self-contained and properly compiled), and there are many examples of it.

----

On the upside: I now see that "dub" provides a good Debian repository, and a HomeBrew formula (and by proxy, a LinuxBrew formula) - so perhaps that is the way to go.

Still, if I may suggest:
There have been recent threads in the mailing list about "the future of D" and creating "Killer Apps" and making D more popular - From my (biased) POV, one big step would be to make D easily useable on more platforms - so the casual (non-windows) users could also experiment with it, and developers would have easier time to distribute software written in D.

Also, as long as DMD is not free, providing easy way to install LDC/GDC is highly desired.

Thanks for reading so far,
  -gordon