www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Installing dmd

reply Georg Wrede <georg.wrede iki.fi> writes:
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.
Mar 01 2009
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Mar 01 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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#Ins
allingDMDonLinuxX86 
 
 

 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...)
Mar 01 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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#Ins
allingDMDonLinuxX86 




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.
Mar 01 2009
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Georg Wrede wrote:


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




 
 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
Mar 01 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
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#Ins
allingDMDonLinuxX86 





 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)
Mar 01 2009
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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
Mar 01 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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?
Mar 01 2009
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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:
==========


/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
=========


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
Mar 01 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
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:
 ==========

 
 /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
 =========

 
 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?
Mar 01 2009
parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Sun, Mar 01, 2009 at 06:56:50PM +0200, Georg Wrede wrote:

 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.


Yah, that's what I use.


 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.


Qt installs itself to /usr/local/Trolltech/Qt-4.version with bin, lib, include,
etc. as subdirectories in there.

It looks like Java and Mono do the same if you manually install them.

Something similar seems like a pretty good choice here too. Maybe:
/usr/local/digitalmars/d1 and /d2


 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?


I think putting the subdirs in /usr/local/whatever is the best option -
it leads to easy installation and also easy uninstallation (though why
would you do that??? :P)

Once there, you can use helper scripts (or symlinks) in /usr/local/bin,
or adjust your PATH.

I'd give instructions for both, probably putting the path instructions first.
(You'd also want to do that on Windows, so it is the most cross platform and
the least invasive method.)


-- 
Adam D. Ruppe
http://arsdnet.net
Mar 01 2009
parent Georg Wrede <georg.wrede iki.fi> writes:
Adam D. Ruppe wrote:

 On Sun, Mar 01, 2009 at 06:56:50PM +0200, Georg Wrede wrote:

 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.


 
 Yah, that's what I use.
 

 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.


 
 Qt installs itself to /usr/local/Trolltech/Qt-4.version with bin, lib, include,
 etc. as subdirectories in there.
 
 It looks like Java and Mono do the same if you manually install them.
 
 Something similar seems like a pretty good choice here too. Maybe:
 /usr/local/digitalmars/d1 and /d2


That looks good!


 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?


 
 I think putting the subdirs in /usr/local/whatever is the best option -
 it leads to easy installation and also easy uninstallation (though why
 would you do that??? :P)
 
 Once there, you can use helper scripts (or symlinks) in /usr/local/bin,
 or adjust your PATH.


Well, symlinks directly to dmd executable don't work, because dmd 
doesn't then have access to its own name, which it needs to find 
everything in the tree. And adding to path would require that you rename 
all the different dmd compilers with different names, which is too much 
work, and confusing.

So, depending on, if one wants to have access to one dmd version at a 
time, or if one wants to compile even simultaneously (like in two 
windows) with different dmd versions, there are about two choices.

Let's assume one has ended up having

$ ls /usr/local/digitalmars
dmd2025 dmd1040

Then either

A:

create a symlink
$ cd
$ ln -s /usr/local/digitalmars/dmd2025 dmd

Now edit your ~/.bash_profile to contain

export PATH=$PATH:~/dmd/linux/bin

And everything should work the next time you login.

Once you're done with dmd2025 and want to use dmd1040 simply do

$ cd
$ rm dmd
$ ln -s /usr/local/digitalmars/dmd1040 dmd

and you're ready to use the old version.


OR if you want to use both new and old all the time, then

B:

edit your ~/.bashrc to contain the following lines

alias dmd1=/usr/local/digitalmars/dmd1040/linux/bin/dmd
alias dmd2=/usr/local/digitalmars/dmd2025/linux/bin/dmd

and then possibly do the same for dumpobj obj2asm and rdmd, if you feel 
you'll use them often enough not to bother writing the whole path to 
them each time.

At next login you can compile anything using either

$ dmd1 myfile.d
$ dmd2 myfile.d

(which is essentially how I plan on having it.)

(And when this didn't work, one obviously had forgotten to do the chmod. 
:-) )


 I'd give instructions for both, probably putting the path instructions first.
 (You'd also want to do that on Windows, so it is the most cross platform and
 the least invasive method.)
Mar 01 2009