I agree.  I like Olaf's getexecpath function.  Given that, why fool around with /etc?

Bill

Georg Wrede wrote:
> The readme.linux (v65) tells me to edit dmd.conf and put it in /etc and to put
> libphobos.a in /usr/lib.
> 
> This leads to two things:
> 
> - Dmd cannot be tried on a machine where the user does
> not have root rights. - There can be only one version of phobos source files
> on a given machine.
> 
> I got thinking. Since dmd is currently far from production code (no offence), it
> probably will be installed by individuals only. The same individual, or somebody
> else on the same machine may want to try another version, right?
> 
> Maybe we should go for the single-hierarchy install? At least for now? 
> 
> Later, when new versions come out more slowly, then we could return to the issue
> of "what is the right place to spew all the files". Preferably this could be
> together with testing and creating an rpm package.  (Heck, by that time we'll
> have enough gurus here to take care of the entire rpm pakaging?)
> 
> This would give us time to get the "spewing" done right from the start, too?
> 
> ---
> 
> The variable $HOME is guaranteed to be defined in Unix, and it points to the
> home directory. 
> 
> Config files in home directory should not be visible when doing a ls or ls -l
> and therefore they should have names starting with a dot, like .dmd or .bashrc.
> 
> Why not have version specific files (.dmd64, .dmd65, etc.) in home directory?
> All they would contain is the path to dmd-home for that version! This way the
> old versions would not hinder trying a newer one. 
> 
> Switching between versions could be as easy as changing a link in $HOME/bin
> directory. Instead of having the dmd/bin directory in your path, you add a
> "virtual" path to it.
> 
> PATH=$PATH:$HOME/bin/dmdpath
> 
> All you have to do is
> 
> ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin
> 
> to switch to v65. (This looks cumbersome to non-unixers, I know.) This way the
> user can install any number of different versions, and have them wherever he
> wishes.
> 
> ---
> 
> To recap, all the binary has to do is read $HOME/.dmd[myver] to know where
> everything is.
> 
> This gives the (often pathologically individualistic) linux programmers freedom
> to setup everything as they wish, while still being easy on Walter <g>.
> 
> Oh, I almost forgot: here's a script for post-unzipping:
> 
> #!/bin/sh
> MYVER=66
> cat $PWD > $HOME/.dmd$MYVER
> cd bin
> chmod u+x dmd obj2asm dumpobj
> 
> 
> 

I'm sorry, the obligatory bug fixes:

In article <b9qpgf$1bu8$1@digitaldaemon.com>, Georg Wrede says...
>
>PATH=$PATH:$HOME/bin/dmdpath

should be

PATH=$PATH:$HOME/bin/dmdbin

>ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin

should be

ln -sf `echo $HOME/.dmd65`/bin $HOME/bin/dmdbin

Sorry about the two replies, but one more comment:

I currently have TWO versions of gcc installed, a stable one, and an experimental one.  We test with both.  If we ever ship D-based code, I probably will do the same.  My point is that supporting two versions of dmd at the same time is an important long-term capability.

Bill

Bill Cox wrote:
> I agree.  I like Olaf's getexecpath function.  Given that, why fool around with /etc?
> 
> Bill
> 
> Georg Wrede wrote:
> 
>> The readme.linux (v65) tells me to edit dmd.conf and put it in /etc and to put
>> libphobos.a in /usr/lib.
>>
>> This leads to two things:
>>
>> - Dmd cannot be tried on a machine where the user does
>> not have root rights. - There can be only one version of phobos source files
>> on a given machine.
>>
>> I got thinking. Since dmd is currently far from production code (no offence), it
>> probably will be installed by individuals only. The same individual, or somebody
>> else on the same machine may want to try another version, right?
>>
>> Maybe we should go for the single-hierarchy install? At least for now?
>> Later, when new versions come out more slowly, then we could return to the issue
>> of "what is the right place to spew all the files". Preferably this could be
>> together with testing and creating an rpm package.  (Heck, by that time we'll
>> have enough gurus here to take care of the entire rpm pakaging?)
>>
>> This would give us time to get the "spewing" done right from the start, too?
>>
>> ---
>>
>> The variable $HOME is guaranteed to be defined in Unix, and it points to the
>> home directory.
>> Config files in home directory should not be visible when doing a ls or ls -l
>> and therefore they should have names starting with a dot, like .dmd or .bashrc.
>>
>> Why not have version specific files (.dmd64, .dmd65, etc.) in home directory?
>> All they would contain is the path to dmd-home for that version! This way the
>> old versions would not hinder trying a newer one.
>> Switching between versions could be as easy as changing a link in $HOME/bin
>> directory. Instead of having the dmd/bin directory in your path, you add a
>> "virtual" path to it.
>>
>> PATH=$PATH:$HOME/bin/dmdpath
>>
>> All you have to do is
>>
>> ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin
>>
>> to switch to v65. (This looks cumbersome to non-unixers, I know.) This way the
>> user can install any number of different versions, and have them wherever he
>> wishes.
>>
>> ---
>>
>> To recap, all the binary has to do is read $HOME/.dmd[myver] to know where
>> everything is.
>>
>> This gives the (often pathologically individualistic) linux programmers freedom
>> to setup everything as they wish, while still being easy on Walter <g>.
>>
>> Oh, I almost forgot: here's a script for post-unzipping:
>>
>> #!/bin/sh
>> MYVER=66
>> cat $PWD > $HOME/.dmd$MYVER
>> cd bin
>> chmod u+x dmd obj2asm dumpobj
>>
>>
>>
> 

Correcting correcting correcting... maybe I should go to sleep.

In article <b9qqth$1d5d$1@digitaldaemon.com>, Georg Wrede says...
>
>I'm sorry, the obligatory bug fixes:
>
>In article <b9qpgf$1bu8$1@digitaldaemon.com>, Georg Wrede says...
>
>>ln -sf `cat $HOME/.dmd65`/bin $HOME/bin/dmdbin
>
>should be
>
>ln -sf `echo $HOME/.dmd65`/bin $HOME/bin/dmdbin

No, it was right, so have cat there.

But cat was wrong in another place:

>    #!/bin/sh
>    MYVER=66
>    cat $PWD > $HOME/.dmd$MYVER
>    cd bin
>    chmod u+x dmd obj2asm dumpobj

here the echo, thus:

echo $PWD > $HOME/.dmd$MYVER

I agree.

"Bill Cox" <bill@viasic.com> wrote in message news:3EC0F0D0.3050603@viasic.com...
> Sorry about the two replies, but one more comment:
>
> I currently have TWO versions of gcc installed, a stable one, and an experimental one.  We test with both.  If we ever ship D-based code, I probably will do the same.  My point is that supporting two versions of dmd at the same time is an important long-term capability.
>
> Bill