Just downloaded dmd. It's been a while since I last did it.

I was flabbergasted to find that there was no INSTALL.TXT, or at the very least a mention in README.TXT about where to look for instructions.

(Yes, I found ./html/d/dmd-linux.html but it is not proper to have the user, especially the non-D-familiar user, be sent on a chase.)


On Linux, the installation is an amazing mixture of private and public install. On the one hand, the doc has you put the files below home, but still dmd.conf in /etc, which is a public and root-only writable directory.

To any Linux user this looks *home-made* and *amateurish*, actually childish.


Instead, an INSTALL.TXT has to be there, you can't expect one to fire up a graphic user interface just to read the html docs -- especially when the program to be installed is strictly non-GUI!

And it should be in TWO parts. One part explains how to install dmd for yourself only. (A "user install".) Another part should explain how to install dmd for everybody. (A "root install".)

Even if few here share their laptop with others, the UNIX *way* is to assume several simultaneous users on the computer. (Hell, it's not even uncommon for dorm residents to pool their money, and buy a serious computer, but with two screens and two keyboards. (Yes, I know this is unthinkable for Windows people.)


What this all comes down to, is, one should be able to install dmd for himself, without root privileges, and another user maybe a different version of dmd for herself. And a company should be able to install dmd for everybody on a computer.

----

I suspect there are some real or perceived difficulties with this? But that's why we have this newsgroup. This embarrasment simply has to go away.

As a side benefit, fixing this most probably yields an easy (and documented) way to conveniently have several dmd versions installed and usable. For example, D1 and D2, or the last dmd for research and an older one for a multi-month pay project.

Georg Wrede wrote:

> What this all comes down to, is, one should be able to install dmd for himself, without root privileges, and another user maybe a different version of dmd for herself. And a company should be able to install dmd for everybody on a computer.

The instructions was added to Wiki4D, hoping they would be included:
http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler#InstallingDMDonLinuxX86

> As a side benefit, fixing this most probably yields an easy (and documented) way to conveniently have several dmd versions installed and usable. For example, D1 and D2, or the last dmd for research and an older one for a multi-month pay project.

I have D1 installed as "dmd" and D2 installed as "dmd2", it takes
some tricks to have it read /etc/dmd.conf and /etc/dmd2.conf though.

--anders

On Sun, Mar 01, 2009 at 02:43:08PM +0200, Georg Wrede wrote:
> I suspect there are some real or perceived difficulties with this? But that's why we have this newsgroup. This embarrasment simply has to go away.

On my system, I don't actually 'install' it; I unzip it and run it from that directory (actually I put a script to run it in my PATH, but I don't move the executable at all). If that directory is private, it is a one user install. If it is public, it works for everyone.

It just works, even for version 1 and 2 at the same time.
Haven't tried the newest releases yet so it might be
broken, but I never understand why people have so many problems with this.

-- 
Adam D. Ruppe
http://arsdnet.net

Anders F Björklund wrote:
> Georg Wrede wrote:
> 
>> What this all comes down to, is, one should be able to install dmd for himself, without root privileges, and another user maybe a different version of dmd for herself. And a company should be able to install dmd for everybody on a computer.
> 
> The instructions was added to Wiki4D, hoping they would be included:
> http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler#InstallingDMDonLinuxX86 
> 
> 
>> As a side benefit, fixing this most probably yields an easy (and documented) way to conveniently have several dmd versions installed and usable. For example, D1 and D2, or the last dmd for research and an older one for a multi-month pay project.
> 
> I have D1 installed as "dmd" and D2 installed as "dmd2", it takes
> some tricks to have it read /etc/dmd.conf and /etc/dmd2.conf though.
> 
> --anders

To my surprise, this seems to work:

$ cd Download
$ unzip dmd.1.040.zip
$ mv dmd dmd1040
$ unzip dmd.2.025.zip
$ mv dmd dmd2025
$ alias d1=/home/georg/Download/dmd1040/linux/bin/dmd
$ alias d2=/home/georg/Download/dmd2025/linux/bin/dmd
$ chmod u+x /home/georg/Download/dmd1040/linux/bin/dmd
$ chmod u+x /home/georg/Download/dmd2025/linux/bin/dmd
$ cd /tmp
$ vi ver.d
$ cat ver.d
import std.stdio;
import std.compiler;

void main()
{
  writefln("Version %d.%d", version_major, version_minor);
}
$ d1 ver.d
$ ./ver
Version 1.40
$ mv ver ver1
$ d2 ver.d
$ ./ver
Version 2.25


This leads one to expect that most of the job is done!

Now you actually can have several D versions as non-root installs!!

I wonder if there are some unexpected gotchas or caveats?

(And no, I don't have binaries in Download like this, it's just a test...)

Georg Wrede wrote:
> Anders F Björklund wrote:
>> Georg Wrede wrote:
>>
>>> What this all comes down to, is, one should be able to install dmd for himself, without root privileges, and another user maybe a different version of dmd for herself. And a company should be able to install dmd for everybody on a computer.
>>
>> The instructions was added to Wiki4D, hoping they would be included:
>> http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler#InstallingDMDonLinuxX86 

So right now it looks like even those instructions are outdated.

The very minimum is to unzip, chmod and then it's all go, IF one bothers to write the full path to dmd each time.

The rest is convenience, i.e. either putting dmd on your path (not recommended if one has several versions of dmd), or making an alias for (each) dmd, or creating shell scripts in your ~/bin to start each.

What one can't do instead of the above, (and I'm okay with that) is to link from ~/bin to the actual dmd, since then dmd won't find its own full name, and therefore not the libraries and stuff.

>>> As a side benefit, fixing this most probably yields an easy (and documented) way to conveniently have several dmd versions installed and usable. For example, D1 and D2, or the last dmd for research and an older one for a multi-month pay project.
>>
>> I have D1 installed as "dmd" and D2 installed as "dmd2", it takes
>> some tricks to have it read /etc/dmd.conf and /etc/dmd2.conf though.
>>
>> --anders
> 
> To my surprise, this seems to work:
> 
> $ cd Download
> $ unzip dmd.1.040.zip
> $ mv dmd dmd1040
> $ unzip dmd.2.025.zip
> $ mv dmd dmd2025
> $ alias d1=/home/georg/Download/dmd1040/linux/bin/dmd
> $ alias d2=/home/georg/Download/dmd2025/linux/bin/dmd
> $ chmod u+x /home/georg/Download/dmd1040/linux/bin/dmd
> $ chmod u+x /home/georg/Download/dmd2025/linux/bin/dmd
> $ cd /tmp
> $ vi ver.d
> $ cat ver.d
> import std.stdio;
> import std.compiler;
> 
> void main()
> {
>   writefln("Version %d.%d", version_major, version_minor);
> }
> $ d1 ver.d
> $ ./ver
> Version 1.40
> $ mv ver ver1
> $ d2 ver.d
> $ ./ver
> Version 2.25
> 
> 
> This leads one to expect that most of the job is done!
> 
> Now you actually can have several D versions as non-root installs!!
> 
> I wonder if there are some unexpected gotchas or caveats?
> 
> (And no, I don't have binaries in Download like this, it's just a test...)

So, thanks Walter, the compiler works real cool now!!!!

It's just the documentation that needs a touch-up.

Adam D. Ruppe wrote:
> On Sun, Mar 01, 2009 at 02:43:08PM +0200, Georg Wrede wrote:
>> I suspect there are some real or perceived difficulties with this? But that's why we have this newsgroup. This embarrasment simply has to go away.
> 
> On my system, I don't actually 'install' it; I unzip it and run it
> from that directory (actually I put a script to run it in my PATH, but
> I don't move the executable at all). If that directory is private, it
> is a one user install. If it is public, it works for everyone.
> 
> It just works, even for version 1 and 2 at the same time.
> Haven't tried the newest releases yet so it might be
> broken, but I never understand why people have so many problems with this.

This looks excellent!

So it's just the docs?

Georg Wrede wrote:

>>> The instructions was added to Wiki4D, hoping they would be included:
>>> http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler#InstallingDMDonLinuxX86 
> 
> So right now it looks like even those instructions are outdated.

Not too surprising, as they were written in 2005...
Could maybe need some updating on the directories ?

> The very minimum is to unzip, chmod and then it's all go, IF one
> bothers to write the full path to dmd each time.

Doing the chmod, and converting from DOS linefeeds,
would not be needed if it shipped as a tarball too.

--anders

On Sun, Mar 01, 2009 at 05:37:05PM +0200, Georg Wrede wrote:
> This looks excellent!
> 
> So it's just the docs?

Yeah, the docs are overcomplicated. (I have to admit I never read them;
I just did the same thing I've been doing with dmc for years and it worked.)

Let me do a 'clean' install of the new version and record my steps here. The goal: have dmd for D 1 and D 2 both working at the same time for native binaries.

Secondary goal (something else I have working here): have the Windows dmd working under Wine for building Windows exes from Linux.



First, I download the dmd zip files (I always get them from the changelog page.)

To have both 1.0 and 2.0 side by side, we'll make different directories for them and put the respective zip file in that directory:

mkdir d2
mv dmd.2* d2
mkdir d1
mv dmd.1* d1

Go in and unzip it:

cd d2
unzip dmd.2*

Change the permissions (actually optional, see the end of this message for an
alternative):

cd dmd/linux/bin
chmod +x dmd
chmod +x dumpobj
chmod +x obj2asm
chmod +x rdmd


Now, it works, but we want it in our path. To do this, I just stick a script in my path:

Create a file: /usr/bin/dmd with the contents:
==========
#!/bin/bash

/path/to/your/download/folder/d2/dmd/linux/bin/dmd $*
==========
Make it executable:
chmod +x /usr/bin/dmd

And boom, you can now run:

dmd test.d

And it works correctly.


Repeat the process for the D1 download, but call your convenience script something else. I personally use /usr/bin/dmd-1.0 but you can do whatever you want.

Now:
dmd test.d
It works!

dmd-1.0 testv1.d
It works too!

What about making Windows binaries?

It is trivial:

wine /path/to/your/download/d2/dmd/windows/bin/dmd.exe test.d

Boom, it worked too! Again, you might want a convenience script:

/usr/bin/dmd-win
=========
#!/bin/bash

wine /path/to/your/download/d2/dmd/windows/bin/dmd.exe $* =========

(And repeat for D1.) And now you can make Linux or Windows binaries with D1 or D2, all side by side, all with ease.


When you want to update your compiler, simply grab the new zip in the same download folder, unzip it, overwriting the old ones, chmod +x linux/bin/dmd, and have fun.


Btw, if chmoding it every time is too much of a hassle, your convenience scripts can render that unneeded too.

Just use

========
/bin/bash

/lib/ld-linux.so.2 /path/to/your/download/d2/dmd/linux/bin/dmd $* ==========

Instead. Thus you don't need to chmod +x the file from the zip.

If you go that way, updating your compiler is as simple as downloading the new zip and unzipping it over your old install.



For a private install, just put your convenience scripts somewhere in your home dir and add them to your path.

For a public install, make sure your download directory is world readable.


-- 
Adam D. Ruppe
http://arsdnet.net

Anders F Björklund wrote:
> Georg Wrede wrote:
> 
>>>> The instructions was added to Wiki4D, hoping they would be included:
>>>> http://prowiki.org/wiki4d/wiki.cgi?D__Tutorial/InstallingDCompiler#InstallingDMDonLinuxX86 
>>
>>
>> So right now it looks like even those instructions are outdated.
> 
> Not too surprising, as they were written in 2005...
> Could maybe need some updating on the directories ?
> 
>> The very minimum is to unzip, chmod and then it's all go, IF one
>> bothers to write the full path to dmd each time.
> 
> Doing the chmod, and converting from DOS linefeeds,
> would not be needed if it shipped as a tarball too.

True.

Seems the man files have *some* lines with ^M^J, some with only ^J.


Actually, Walter could still have a single tree, but just have a shell script on a linux machine that takes as input the newly created Windows .zip and output the .tar file (or even better, a .tgz).

The script would essentially unpack, chmod, (maybe rm unneeded crap), and then tar the tree.


That sounds complicated, (it isn't!) but I fear that one can't avoid the chmod if the tree is tarred on Windows, because there is no x bit in the directory listing. (IIRC)

Adam D. Ruppe wrote:
> On Sun, Mar 01, 2009 at 05:37:05PM +0200, Georg Wrede wrote:
>> This looks excellent!
>>
>> So it's just the docs?
> 
> Yeah, the docs are overcomplicated. (I have to admit I never read them;
> I just did the same thing I've been doing with dmc for years and it worked.)
> 
> Let me do a 'clean' install of the new version and record my steps here.
> The goal: have dmd for D 1 and D 2 both working at the same time for native
> binaries.
> 
> Secondary goal (something else I have working here): have the Windows dmd
> working under Wine for building Windows exes from Linux.
> 
> 
> 
> First, I download the dmd zip files (I always get them from the changelog page.)
> 
> To have both 1.0 and 2.0 side by side, we'll make different directories for
> them and put the respective zip file in that directory:
> 
> mkdir d2
> mv dmd.2* d2
> mkdir d1
> mv dmd.1* d1
> 
> Go in and unzip it:
> 
> cd d2
> unzip dmd.2*
> 
> Change the permissions (actually optional, see the end of this message for an
> alternative):
> 
> cd dmd/linux/bin
> chmod +x dmd
> chmod +x dumpobj
> chmod +x obj2asm
> chmod +x rdmd
> 
> 
> Now, it works, but we want it in our path. To do this, I just stick a script
> in my path:
> 
> Create a file: /usr/bin/dmd with the contents:
> ==========
> #!/bin/bash
> 
> /path/to/your/download/folder/d2/dmd/linux/bin/dmd $*
> ==========
> Make it executable:
> chmod +x /usr/bin/dmd
> 
> And boom, you can now run:
> 
> dmd test.d
> 
> And it works correctly.
> 
> 
> Repeat the process for the D1 download, but call your convenience script
> something else. I personally use /usr/bin/dmd-1.0 but you can do whatever
> you want.
> 
> Now:
> dmd test.d
> It works!
> 
> dmd-1.0 testv1.d
> It works too!
> 
> What about making Windows binaries?
> 
> It is trivial:
> 
> wine /path/to/your/download/d2/dmd/windows/bin/dmd.exe test.d
> 
> Boom, it worked too! Again, you might want a convenience script:
> 
> /usr/bin/dmd-win
> =========
> #!/bin/bash
> 
> wine /path/to/your/download/d2/dmd/windows/bin/dmd.exe $*
> =========
> 
> (And repeat for D1.) And now you can make Linux or Windows binaries with D1
> or D2, all side by side, all with ease.
> 
> 
> When you want to update your compiler, simply grab the new zip in the same
> download folder, unzip it, overwriting the old ones, chmod +x linux/bin/dmd,
> and have fun.
> 
> 
> Btw, if chmoding it every time is too much of a hassle, your convenience
> scripts can render that unneeded too.
> 
> Just use
> 
> ========
> /bin/bash
> 
> /lib/ld-linux.so.2 /path/to/your/download/d2/dmd/linux/bin/dmd $*
> ==========
> 
> Instead. Thus you don't need to chmod +x the file from the zip.

That's a neat one!!!

> If you go that way, updating your compiler is as simple as downloading
> the new zip and unzipping it over your old install.
> 
> 
> 
> For a private install, just put your convenience scripts somewhere in your
> home dir and add them to your path.

Ever since stone age, one's PATH contains ~/bin for one's own binaries. I believe this is with all Linux distros, and IIRC on Solaris. Probably on OSX too. The ~/bin isn't created for you, but that's the canonical place for the small dmd invocators.

> For a public install, make sure your download directory is world readable.

I was just trying to figure out what the INSTALL.TXT should say about that. Somehow /usr/local/bin would seem the right place, but it doesn't usually contain other than executables, and certainly not subdirectories.

So looks like the dmd tree has to be put somewhere else.

OTOH, http://www.faqs.org/docs/linux_admin/x542.html says that no distro is allowed to put anything here because it is reserved for stuff the local admin wants to install. Now, D being a "manual install" thing, it rightfully could reside here.

Only problem is that subdirectories of /usr/local/bin aren't in the path, so one would have to create here the starter scripts you've done.

Any ideas?