Parallel Install

Unknown W. Brackets unknown at simplemachines.org
Wed Jan 23 15:54:41 PST 2008


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.




More information about the Digitalmars-d mailing list