www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Parallel Install

reply Jesse Phillips <jessekphillips gmail.com> writes:
One of the things I think dmd v1 and v2 should do is make it easier to 
both versions on the same computer. gcc lets you do this and is used very 
often especially when it comes to using kernel headers. I do not think 
that the current state of dmd needs such an ability, but I see it will be 
good for when it is used more and dmd v2 is finally released.

At this time I have successfully been able to install any number of dmd 
versions to my Debian system. There was not much work involved as it only 
required a few name changes. The dmd executable had the version number 
appended to it, along with libphobos.a. It also required having a the 
source code for phobos in a correctly version-ed directory. The main 
problem with this was the switching of which compiler version I was 
using. If I want to run dmd2.010 I would need to make sure that dmd.conf 
pointed to the correct phobos directory.

Since I believe that there is no reason v1.015 can't use v1.023's 
libphobos.a and the phobos source, I think it would be great if dmd was 
packages where dmd was named with its version (dmd1.023) and that 
libphobos/phobos source would have the major version added (libphobos1.a/
phobos1). And the last thing would be to have dmd.conf expanded to allow 
for specifying the Environment related to the version.

I think that this will be a good practice as use of D increases. I 
realize that after v2 is released, v1 is not getting support. However, 
projects made for v1 will not compile in v2, and it is likely older 
projects that are either complete or dead will not be updated. This could 
be true in business where an older program was developed in an older 
build, but newer software is being done in the latest stable build. There 
is also the fun factor, development is done in the stable release and 
then the beta/alpha builds are just there to try it and get familiar.
Jan 23 2008
next sibling parent reply BCS <BCS pathlink.com> writes:
Jesse Phillips wrote:
[...]


random thought: what would it take to make a front end (also called DMD)
Jan 23 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
BCS wrote:

 Jesse Phillips wrote:
 [...]
 
 
 random thought: what would it take to make a front end (also called DMD) 



That sounds like a VERY good idea. But you'd have to have the binaries 
of every DMD you'd want to support (which I guess wouldn't be so bad, 
since they're small).
Jan 23 2008
prev sibling parent reply Unknown W. Brackets <unknown simplemachines.org> writes:
On Windows, this is easy.  I have it setup so I can type a single command to
switch between dmd1 and dmd2.  This is common practice with Linux as well; I
believe it's called "gcc-config"?

All it does is update symlinks.  So you might have /opt/dmd/1.017 and
/opt/dmd/1.023... then you type dmd-config 1.017 and all symlinks point to the
files within that folder.  This is very simple and works without extra effort
from the software author.

I'm sure something similar could be set up for dmd.  In any case, it's really a
matter of making things like this easier.

-[Unknown]


Jesse Phillips Wrote:


 One of the things I think dmd v1 and v2 should do is make it easier to 
 both versions on the same computer. gcc lets you do this and is used very 
 often especially when it comes to using kernel headers. I do not think 
 that the current state of dmd needs such an ability, but I see it will be 
 good for when it is used more and dmd v2 is finally released.
 
 At this time I have successfully been able to install any number of dmd 
 versions to my Debian system. There was not much work involved as it only 
 required a few name changes. The dmd executable had the version number 
 appended to it, along with libphobos.a. It also required having a the 
 source code for phobos in a correctly version-ed directory. The main 
 problem with this was the switching of which compiler version I was 
 using. If I want to run dmd2.010 I would need to make sure that dmd.conf 
 pointed to the correct phobos directory.
 
 Since I believe that there is no reason v1.015 can't use v1.023's 
 libphobos.a and the phobos source, I think it would be great if dmd was 
 packages where dmd was named with its version (dmd1.023) and that 
 libphobos/phobos source would have the major version added (libphobos1.a/
 phobos1). And the last thing would be to have dmd.conf expanded to allow 
 for specifying the Environment related to the version.
 
 I think that this will be a good practice as use of D increases. I 
 realize that after v2 is released, v1 is not getting support. However, 
 projects made for v1 will not compile in v2, and it is likely older 
 projects that are either complete or dead will not be updated. This could 
 be true in business where an older program was developed in an older 
 build, but newer software is being done in the latest stable build. There 
 is also the fun factor, development is done in the stable release and 
 then the beta/alpha builds are just there to try it and get familiar.
Jan 23 2008
parent reply Sean Kelly <sean f4.ca> writes:
Unknown W. Brackets wrote:

 On Windows, this is easy.  I have it setup so I can type a single command to
switch between dmd1 and dmd2.  This is common practice with Linux as well; I
believe it's called "gcc-config"?


On Windows, I just install DMD 1.0 to /dmd and DMD 2.0 to /dmd2, and
rename the DMD 2.0 executable to dmd2.exe.  Both /bin directories are in
my path, and I can call either as needed, so building against 1.0 is:

    dmd myapp.d

And building against 2.0 is:

    dmd2 myapp.d

This may not be ideal for a production setup, but it's just fine for
testing and such.


Sean
Jan 23 2008
next sibling parent reply Dan <murpsoft hotmail.com> writes:
Sean Kelly Wrote:


 Unknown W. Brackets wrote:

 On Windows, this is easy.  I have it setup so I can type a single command to
switch between dmd1 and dmd2.  This is common practice with Linux as well; I
believe it's called "gcc-config"?


 
 On Windows, I just install DMD 1.0 to /dmd and DMD 2.0 to /dmd2, and
 rename the DMD 2.0 executable to dmd2.exe.  Both /bin directories are in
 my path, and I can call either as needed, so building against 1.0 is:
 
     dmd myapp.d
 
 And building against 2.0 is:
 
     dmd2 myapp.d
 
 This may not be ideal for a production setup, but it's just fine for
 testing and such.
 Sean


Ah cool, I guess I just never thought to do that.  

Are most folk's writing production programs in D 2.x or still the D 1.x line?
Jan 23 2008
parent Jesse Phillips <jessekphillips gmail.com> writes:
On Wed, 23 Jan 2008 23:38:33 -0500, Dan wrote:


 Sean Kelly Wrote:
 

 Unknown W. Brackets wrote:

 On Windows, this is easy.  I have it setup so I can type a single
 command to switch between dmd1 and dmd2.  This is common practice
 with Linux as well; I believe it's called "gcc-config"?


 
 On Windows, I just install DMD 1.0 to /dmd and DMD 2.0 to /dmd2, and
 rename the DMD 2.0 executable to dmd2.exe.  Both /bin directories are
 in my path, and I can call either as needed, so building against 1.0
 is:
 
     dmd myapp.d
 
 And building against 2.0 is:
 
     dmd2 myapp.d
 
 This may not be ideal for a production setup, but it's just fine for
 testing and such.
 Sean


 
 Ah cool, I guess I just never thought to do that.
 
 Are most folk's writing production programs in D 2.x or still the D 1.x
 line?


I would assume that it is still in version 1. My concern is more tuned to 
when work moves to v2, but there are still source in v1 that isn't going 
to be updated for whatever reason.
Jan 23 2008
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On Jan 24, 2008 12:46 AM, Sean Kelly <sean f4.ca> wrote:

 On Windows, I just install DMD 1.0 to /dmd and DMD 2.0 to /dmd2, and
 rename the DMD 2.0 executable to dmd2.exe.  Both /bin directories are in
 my path, and I can call either as needed, so building against 1.0 is:


Those don't look like Windows pathnames to me, but I use a similar
solution. I install (that is, unzip the zip files) one version into
C:\, and another version into D:\. It works a treat.
Jan 24 2008