On 02/25/2014 10:06 AM, Dicebot wrote:
> On Tuesday, 25 February 2014 at 14:51:48 UTC, Assaf Gordon wrote:
>> 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.
>
> Then push it into distro repositories. You are NOT helping by
> recommending them to do "make install", quite the contrary, harming
> whole ecosystem. Casual users should not be even aware that "make
> install" exists. Being one of package maintainers myself I really
> hate this kind of "helping" attitude, it causes only trouble.

I'm sorry it makes you upset - I can see how frustrating it is for a package maintainer.

But I think "harming the ecosystem" is a bit of a hyperbole - in an ideal world where Linux Distros contain every piece of software (and up to date version), there is indeed very little need to install from source.

But there are several real-world constraints, at least in the environment I work in:

1. Software needs to run on variety of servers and distributions, some are very old (e.g. CentOS 5.4 or Ubuntu 10.04).
Upgrading is not an option for these environments.

2. Software needs to be installed without root - to a user directory (i.e. using "configure --prefix" or similar).

3. Software is updated too frequently, or is too new, or (sadly) too experimental (code-wise) for inclusion in a stable distribution package - but it still needs to be used.

4. It takes time for a software to be properly packaged, and users want to install it now. Also - it will not be available in the "stable" branch of the distribution.

In addition, some distribution have extra requirements.
For example, Debian frowns upon compiling with static libraries when a shared one is available.

If there is already a package in official Debian which is written in D, it would be very helpful to see an example of the packaging process.

>>> 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.
>
> Except you never have truly statically linked binaries, there is
> always at least glibc.

I'm not sure I understand this statement.
If I link with "gcc -static" and my program is properly built, the resulting binary does not require any library, not even glibc.
It uses only Linux ABI syscalls.
Unless I'm mistaken?

>
> Please stop distributing software for Linux with Windows attitude.

Not sure what the "windows attitude" is, since I haven't developed software for windows in 12 years...

My first choice would be to have a project in D which is easily compilable from source code.
Either with "make" or "dub" or "configure" or anything else.
Once I have that, packaging (for a linux distribution) is straight forward, and so is adding it to HomeBrew/LinuxBrew.

At the moment, I don't think it's possible (in the level of "easiness" comparable with C/autotools-based projects).

The alternative (for linux) is distributing a binary program, and for that, a static-binary is much more portable than a dynamic one.

Having GDC and LDC in Debian is an excellent start - I was not aware of them, and it is certainly the right direction.
But those are still not available in the "stable" branches, and so, not easily usable.
In the future this will definitely change.

-Gordon

On Tuesday, 25 February 2014 at 15:06:14 UTC, Dicebot wrote:
> On Tuesday, 25 February 2014 at 14:51:48 UTC, Assaf Gordon wrote:
>> 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.
>
> Then push it into distro repositories. You are NOT helping by recommending them to do "make install", quite the contrary, harming whole ecosystem. Casual users should not be even aware that "make install" exists. Being one of package maintainers myself I really hate this kind of "helping" attitude, it causes only trouble.

Personally I have to compile all my software by hand at work, because I don't have root/sudo access.
Although I agree that in general one should try to work within the package managers as much as possible, many (most?) distributions don't have even half decent capabilities for source-based distribution within the package manager, especially when working without root.

On Tuesday, 25 February 2014 at 16:04:56 UTC, Assaf Gordon wrote:
> Not sure what the "windows attitude" is, since I haven't developed software for windows in 12 years...

The Windows attitude is expecting things to actually work for the end user. It rarely actually works that way on linux.

On Tuesday, 25 February 2014 at 16:03:46 UTC, Artem Tarasov wrote:
> /usr/bin/ld: cannot find -l:libphobos2.a

Weird. That might just be a config problem.

On 02/25/2014 11:17 AM, Adam D. Ruppe wrote:
> On Tuesday, 25 February 2014 at 16:04:56 UTC, Assaf Gordon wrote:
>> Not sure what the "windows attitude" is, since I haven't developed software for windows in 12 years...
>
> The Windows attitude is expecting things to actually work for the end user. It rarely actually works that way on linux.

Side-stepping the flame-war potential of this statement :) ,

I agree that Windows is homogenous enough, and have so many "built-in" runtime DLLs that you can expect all systems to be almost identical in terms of what's available. It makes distribution very easy for users (and developers).

It takes more effort to build portable software, and in windows you rarely have to worry about it.

Once you do build a portable software properly, it "works" for the end user as well.

On Tuesday, 25 February 2014 at 16:17:13 UTC, Adam D. Ruppe wrote:
> On Tuesday, 25 February 2014 at 16:04:56 UTC, Assaf Gordon wrote:
>> Not sure what the "windows attitude" is, since I haven't developed software for windows in 12 years...
>
> The Windows attitude is expecting things to actually work for the end user. It rarely actually works that way on linux.

If by "works for the end user" you mean that you go to a (different for every app) website and download a binary blob, give it administrator permissions, go through a graphical installer that by default installs 3 toolbars, an anti-virus scanner demo and changes your homepage, then downloads a whole other program that does the actual installation... then yes, I guess it does :)

Honestly, my experience of linux in terms of getting new applications has always been a highlight for me ever since I first started using it years ago.

apt-get install firefox
emerge firefox
pacman -S firefox
yast -i firefox
yum install firefox

How can any of those be said to not work for the end user? It's really very very simple and that's without even discussing the GUIs for the point-and-clickers.

On 2014-02-25 16:21:24 +0000, Adam D. Ruppe said:

> On Tuesday, 25 February 2014 at 16:03:46 UTC, Artem Tarasov wrote:
>> /usr/bin/ld: cannot find -l:libphobos2.a
> 
> Weird. That might just be a config problem.

The dmd.conf file has the wrong options set for the path.  I ran into this problem on MacOS X as well.

-S.

On Tuesday, 25 February 2014 at 16:04:56 UTC, Assaf Gordon wrote:
> But I think "harming the ecosystem" is a bit of a hyperbole - in an ideal world where Linux Distros contain every piece of software (and up to date version), there is indeed very little need to install from source.

Apologise for overly harsh reaction, it is rather frequent source of frustration for me which makes reaction unacceptably nervous.

That "ideal" state is pretty much in your hands. There are as many packages in repos as people are willing to put - not like there is some important boss who decides what needs to be packages.

I know it is not very convenient with Debian because of how conservative it is but in Arch just asking in #archlinux @ freenode is likely to result in kind soul willing to help with packaging questions. Or even easier, just contacting me as it is my direct responsibility to maintain all D-related projects in Arch [community] ;)

As general rule of a thumb - if you application is useful, there always be someone willing to maintain package for it, assuming build process is not utterly insane.

> But there are several real-world constraints, at least in the environment I work in:
>
> 1. Software needs to run on variety of servers and distributions, some are very old (e.g. CentOS 5.4 or Ubuntu 10.04).
> Upgrading is not an option for these environments.
>
> 2. Software needs to be installed without root - to a user directory (i.e. using "configure --prefix" or similar).
>
> 3. Software is updated too frequently, or is too new, or (sadly) too experimental (code-wise) for inclusion in a stable distribution package - but it still needs to be used.
>
> 4. It takes time for a software to be properly packaged, and users want to install it now. Also - it will not be available in the "stable" branch of the distribution.

I see, your requirements do not match use case of a typical desktop application. However, if you are fine with full static linking why not simply distribute binary tarballs for set of systems you want to support? It will put burden of having proper D compilation environment away from the end user.

It is worth noting though that for any normal application requiring package manager access (not full root) is expected and desired. Fast update issue can be solved by providing own upstream repository (i.e. launchpad)

> If there is already a package in official Debian which is written in D, it would be very helpful to see an example of the packaging process.

Unfortunately all Debian/Ubuntu D packages I am aware about are found in non-official repo maintained by Jordi : http://d-apt.sourceforge.net/

Debian is probably hardest distro out there to deal with this kind of stuff.

> I'm not sure I understand this statement.
> If I link with "gcc -static" and my program is properly built, the resulting binary does not require any library, not even glibc.
> It uses only Linux ABI syscalls.
> Unless I'm mistaken?

I think it will work but I'd recommend to provide an option to build system to chose both dynamically and statically linked binary to simplify life for those who _may_ want to package it later.

> Not sure what the "windows attitude" is, since I haven't developed software for windows in 12 years...

I was referring to extremely common attempts to provide all-in-one "installers" ignoring normal practices of target systems that often happen when those used to Windows world start porting their stuff to Linux. And/or thinking about all distros as single target "Linux" system.

> My first choice would be to have a project in D which is easily compilable from source code.
> Either with "make" or "dub" or "configure" or anything else.
> Once I have that, packaging (for a linux distribution) is straight forward, and so is adding it to HomeBrew/LinuxBrew.

dub is the way to go in general, but it is not expected to be ever installed on user systems (well, unless it is Gentoo :)) - it is to be used by you or anyone willing to (re)package your application.

> The alternative (for linux) is distributing a binary program, and for that, a static-binary is much more portable than a dynamic one.

Within your requirements it may be a best choice. In general though I'd say that perfect portability is a flaw rather than merit. When speaking about desktop applications, for exampe, as a user of any operating systems I usually want software that is adapted to conform practices of this specific system and hardly appreciate how portable it is.

On 02/25/2014 05:41 PM, Dicebot wrote:
>
> I see, your requirements do not match use case of a typical desktop
> application.

This is the root cause of our different POVs - I should have explained it more clearly.

My users are people who have access to Linux machines which they do not control.
I can expect them to be able to handle the standard/easy steps of compiling software, but not much more.

This is the case in many universities, were the computer "cluster" is made of whatever Linux the IT department used.
You won't get root access on those servers. And many time the distribution is very old and not updated on purpose (for the sake of stability).
To make matters more complicated, many additional programs are installed in places like "/usr/local/" and "/opt/".
It might make you cringe you as a maintainer (it makes me cringe, as a root-less user) ... but that's life :)

Now, I have to be realistic:
My program will be useful to some degree, but not a life-changing Killer-App.
If it's easy to use and install, people will use it (and by proxy, perhaps use D as well, if they want to hack the code).
If it's too complicated, they'll give up and look for a different solution.

So my goal to begin with, was to find the easiest way to distribute my D program to unix platforms.

>However, if you are fine with full static linking why
> not simply distribute binary tarballs for set of systems you want to
> support? It will put burden of having proper D compilation
> environment away from the end user.
>

We've come full circle :)

In my first message in this thread, I wrote (item #3), that unless I'm missing something, there is no way to build a statically linked binary with D on Linux. If there is a way, I would love to know about it.
I would gladly spend the time to create VMs for each common system setup and package a static binary for it.

 
> I know it is not very convenient with Debian because of how
> conservative it is but in Arch just asking in #archlinux @ freenode
> is likely to result in kind soul willing to help with packaging
> questions. Or even easier, just contacting me as it is my direct
> responsibility to maintain all D-related projects in Arch [community]
> ;)
>

I got one package into Debian, and it took some effort. But it was worth it, because I learned alot, and it did make my program better (distribution wise).
Arch and Gentoo might be friendlier (and HomeBrew/LinuxBrew even easier), but the people I'm aiming for aren't using Arch or Gentoo...

I do have high hopes for HomeBrew/LinuxBrew, as "brew install dmd" and "brew install dub" seems to work nicely on some linux systems.

Best,
 -gordon

On Tuesday, 25 February 2014 at 17:04:11 UTC, John Colvin wrote:
> If by "works for the end user" you mean that you go to a (different for every app) website

I always thought that was the sane way to do it, different website for every app, though I loathe and despise chasing down library dependencies.

static linking ftw

> other program that does the actual installation... then yes, I guess it does :)

Eh, my standard is dmd: get a zip and run the program with a reasonable expectation that it will just work. I don't like installers either.

> How can any of those be said to not work for the end user?

yum install php

gets php 5.1, but my other app needs 5.2

something something epel key whatever

yum update php

got php 5.2! .... but php-gd isn't in that repo, so it still is 5.1 and doesn't work.

wget http://php.net/downloads/whatever/php-5.2.tar.gz
tar zxf blah
cd blah
./configure

missing library X

yum install libx-devel

./configure

missing library Y

yum install liby-devel
no such package

*spend half an hour searching teh web*

yum install libwtf-devel # for some reason liby is in there....

./configure

missing library Z

yum install libz-devel
no such package

wget http://libz.org/downloads/libz.tar.gz
tar zxf
cd
./configure

missing library


You get the idea. finally get that working

cd php
./configure

library Z is version 3.1 but php requries 2.8


here we go again

*six hours later*


OH NO I FORGOT TO ADD --enable-gd TO CONFIGURE :-( :-( :-( here we go again

./configure --enable-gd --enable-whatever-else ....
<snip>
sudo make install

$ php
Segmentation fault



AAaaaAaaAaaaAaaRrrrReGGGHHhhhhGH. OK, I admit, I'm combining two different horror stories into one here, a php one and a recurring hassle I've had with gtk, but still, the point stands.

> It's really very very simple and that's without even
> discussing the GUIs for the point-and-clickers.

When it works, it is great, when it doesn't, you're in a world of pain. Getting into the repo can be a pain too, so can compiling everything.

On Windows, you just compile on your box and it tends to work on others. On Linux, you need a dozen different distros installed to build the compatible binaries to package...