Digital Mars - digitalmars.D - Windows DMD installer

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

As recently posted by WB, we should get a Windows installer project going.  
I think we should first discuss what this installer would contain, which  
installer framework to use, etc.

In my opinion, the Windows installer's goal is somewhat different than a  
Linux installer. I've heard many people say that they'd love a simple  
installer that installs them everything including a build tool, IDE,  
debugger, etc., so perhaps it should allow installing more than just the  
barebones DMD. However, we don't want to include things that many people  
won't use either. Therefore, I was thinking that the installer could  
download and install components (libraries, text editors/IDEs or plugins  
for them, build tools) from the web if the user ticks some corresponding  
checkboxes.

Further ideas:
* support Windows' "change" option in Add/Remove Programs to allow  
removing, reinstalling and updating components
* when installing an editor, associate .d files with it
* adjust PATH to include DMD and any selected build tools
* adjust DMD search paths to point to any additional libraries (Tango,  
DSSS etc.)
* DSSS "net install" integration? (show a checkbox list of libraries)

Going further with this idea, we could remove DMD itself from the  
installer and allow the user to install DMD1/DMD2 as a component, thus  
creating a "meta-installer" to manage the D toolchain.

As for the installer system: I'm familiar with NSIS and InnoSetup, both  
are open-source. NSIS is extensible and can thus download files from the  
Internet, but AFAIK InnoSetup can't (even though it has a more flexible  
scripting language). Windows Installer is also used by some open-source  
software like TortoiseSVN.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jun 27 2009

"Nick Sabalausky" <a a.a> writes:

"Vladimir Panteleev" <thecybershadow gmail.com> wrote in message 
news:op.uv7lme01m02fvl cybershadow...
 As recently posted by WB, we should get a Windows installer project going. 
 I think we should first discuss what this installer would contain, which 
 installer framework to use, etc.

 In my opinion, the Windows installer's goal is somewhat different than a 
 Linux installer. I've heard many people say that they'd love a simple 
 installer that installs them everything including a build tool, IDE, 
 debugger, etc., so perhaps it should allow installing more than just the 
 barebones DMD. However, we don't want to include things that many people 
 won't use either. Therefore, I was thinking that the installer could 
 download and install components (libraries, text editors/IDEs or plugins 
 for them, build tools) from the web if the user ticks some corresponding 
 checkboxes.

 Further ideas:
 * support Windows' "change" option in Add/Remove Programs to allow 
 removing, reinstalling and updating components
 * when installing an editor, associate .d files with it
 * adjust PATH to include DMD and any selected build tools
 * adjust DMD search paths to point to any additional libraries (Tango, 
 DSSS etc.)
 * DSSS "net install" integration? (show a checkbox list of libraries)

 Going further with this idea, we could remove DMD itself from the 
 installer and allow the user to install DMD1/DMD2 as a component, thus 
 creating a "meta-installer" to manage the D toolchain.

 As for the installer system: I'm familiar with NSIS and InnoSetup, both 
 are open-source. NSIS is extensible and can thus download files from the 
 Internet, but AFAIK InnoSetup can't (even though it has a more flexible 
 scripting language). Windows Installer is also used by some open-source 
 software like TortoiseSVN.



- It would be good to have these two presets in addition to 
choose-your-components:
1. All important stuff (Libs + Tools) including the GUI Tools
2. All important stuff (Libs + Tools) but without the GUI Tools

Rationale: Some people are into GUIs and some aren't. Some people already 
have their favorite GUI tools and others might not mind replacing them.

- It would also be good to have these three basic types of downloads 
(generated by some sort of script, of course):

1. A small net-only installer (ie downloads the latest components). There 
should be an option to keep or delete the unpacked downloads after install.

2. An installer packaged with the latest (at the time of packaging) 
components (but can still do a net-install though). This would be available 
in both "with GUI " and "without GUI" flavors. The "without GUI" can of 
course still do an optional net-install of the GUI tools.

3. A no-installer archive that is, to whatever extent possible, 
preconfigured to minimize manual post-extraction configuration, and includes 
well-written instructions for whatever followup steps are needed. This would 
be available in both 7z (best archive format, as far as I know) and zip (for 
people who have yet to join the 21st century and install an archive app that 
can do things like rar and 7z.)

Rationale: Some people like installers, some people hate them. But the 
people who dislike them should still be able to benefit from this all-in-one 
project. Some people want to be able to install offline (and may not always 
have a connection available), others don't care. Some people don't want to 
waste space on components that will eventually become an older version, 
others don't mind and like the sense of security from keeping around the 
installers for whatever they've installed.

Misc:
- FWIW, I've used NSIS in the past and liked it.

- Version control clients (including TortoiseSVN) might be good optional 
components (licenses permitting), since VCSs are used heavily in the D 
scene.

- The net-install capability should also be able to update it's internal 
list of components and defaults (ie without requiring a new version of the 
installer to be downloaded) since projects do sometimes get abandoned or 
replaced by a better alternative, etc.

Jun 27 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

I actually started sketching out a possible installer a few weeks ago.
Here's what I came up with:

First of all, you can't include DMD itself in the installer since the
license doesn't allow for this.

Secondly, it occurred to me that a program like Cygwin's setup might be
a good idea.  That is, instead of installing a single version of a
single compiler to the machine once, it could be "reusable" and provide
the following:

1. Initial install.

First time, it offers to install a compiler, allowing the user to choose
vendor (obviously only DigitalMars for now), the compiler series (1.x or
2.x), either the latest release, a "bleeding-edge" build (which hasn't
undergone testing yet) or a specific version.

It could also offer to install and configure toolchain components.
That's bud, xfBuild, dsss, maybe even IDEs like Poseidon [1]

2. Management.

If you re-run the installer, it should show your installed compilers and
toolchain programs, check for updates and offer to upgrade them.  It
should also allow you to install another compiler in *addition* to any
existing ones, as well as remove them and select which one goes on the
system/user PATH.

3. Diagnostics.

A lot of people get on the NG or IRC complaining about "Can't find
module object.d"  Most of the time, it's because they decided to be
clever and screwed with the layout of the folders when extracting.  It
would be nice to have a button behind which we could run tests for the
most common broken install problems (you rearranged the directories you
thick burke; why did you think this WOULDN'T break it?!)

As for using an installer "tool", I don't think that's really applicable
for something like this.  I say write it in D because otherwise we'll
have people saying that D sucks because we don't use it.  *sigh*



In a larger context, I think what we should probably do is set up a
website or a portion of the wiki for a "Community Toolchain" project.
Get a list of what D needs, what it needs to do and who is working on it
so that people can contribute more easily.

(I actually think we need a proper community-run front page for D, but
that's for another day.)



[1] You think that should be "Acidosis"?  Really, Thunderbird
spell-checker?  REALLY?

Jun 27 2009

"Nick Sabalausky" <a a.a> writes:

"Daniel Keep" <daniel.keep.lists gmail.com> wrote in message 
news:h26unf$1kt9$1 digitalmars.com...
 2. Management.

 If you re-run the installer, it should show your installed compilers and
 toolchain programs, check for updates and offer to upgrade them.  It
 should also allow you to install another compiler in *addition* to any
 existing ones, as well as remove them and select which one goes on the
 system/user PATH.


Yes, very good idea.

 As for using an installer "tool", I don't think that's really applicable
 for something like this.  I say write it in D because otherwise we'll
 have people saying that D sucks because we don't use it.  *sigh*


I'd imagine it'd just be a small minority of boneheads doing that, and 
mostly ones that are just simply looking for *any* reason to dismiss D. I 
think, initially, the most important thing is to have a good system up and 
running with whatever gets us there with the least trouble. *Then* we can 
worry about porting it to D for "purity" and warm fuzzy feelings. And it's 
not like this sort of bootstrapping isn't common for new languages anyway 
(Heck, I bet the JVM still isn't written in Java.) What we certainly don't 
want to do is end up reinventing a full NSIS/InnoWhatever clone in D before 
finally getting around to giving people this important tool.

 (I actually think we need a proper community-run front page for D, but
 that's for another day.)


One can wish...

 [1] You think that should be "Acidosis"?  Really, Thunderbird
 spell-checker?  REALLY?


Hah! :) You know, as much as I like open-source apps, I swear, I have never 
come across a spelling-suggestion engine in an open-source app that was 
actually worth a shit. Ok, maybe I'm exaggerating a bit (and venting), but I 
constantly get so fed up (firefox in particular, but OpenOffice too) with 
suggestion systems that never have the word I'm looking for unless my guess 
just happened to be an unbelievably tiny hamming distance away. Have you 
ever found yourself rewriting the same misspelled word numerous incorrect 
ways just to get the stupid checker to figure it out? I do that constantly. 
It'd probably be quicker just to grab a real dictionary.

Jun 28 2009

BCS <none anon.com> writes:

Hello Daniel,

 I actually started sketching out a possible installer a few weeks ago.
 Here's what I came up with:
 
 First of all, you can't include DMD itself in the installer since the
 license doesn't allow for this.


with Walter's blessing you can. Tango goes this way.

 As for using an installer "tool", I don't think that's really
 applicable for something like this.  I say write it in D because
 otherwise we'll have people saying that D sucks because we don't use
 it.


Um, I've got to say I think you are wrong on this. Installer tools will cut 
the effort to produce this by like 90%. I'd rather see that time spent on 
just about anything rather than using D just so we can say we do.

Jun 28 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

BCS wrote:
 Hello Daniel,
 
 I actually started sketching out a possible installer a few weeks ago.
 Here's what I came up with:

 First of all, you can't include DMD itself in the installer since the
 license doesn't allow for this.


 with Walter's blessing you can. Tango goes this way.


But technically, the people who download it then can't redistribute it.
 I just think it's simpler to have the installer download the zip file
itself and avoid the problem in its entirety.

(Incidentally, I actually already have permission from Walter to
redistribute DMD; a professor at uni wanted to take a peek so I put
together an installer.)

 As for using an installer "tool", I don't think that's really
 applicable for something like this.  I say write it in D because
 otherwise we'll have people saying that D sucks because we don't use
 it.


 Um, I've got to say I think you are wrong on this. Installer tools will
 cut the effort to produce this by like 90%. I'd rather see that time
 spent on just about anything rather than using D just so we can say we do.


I've never met one that could do the sorts of tasks I'm proposing.  If
such a tool does exist, then fantastic; let's use that.

Jun 28 2009

BCS <none anon.com> writes:

Hello Daniel,

 BCS wrote:
 
 Hello Daniel,
 
 I actually started sketching out a possible installer a few weeks
 ago. Here's what I came up with:
 
 First of all, you can't include DMD itself in the installer since
 the license doesn't allow for this.
 


 


 it.
 I just think it's simpler to have the installer download the zip file
 itself and avoid the problem in its entirety.


I guess it's just that an installer that needs anything else (including an 
internet connection) to install seems utterly pointless to me. In my book 
an installer is firstly the data to be installed and secondly a tool to
configure 
it. When I download an installer, I want to know that it will work where 
ever and when ever I have that file. Even if Walter decides to shutdown
digitalmars 
so he can go off and become a monk.

 (Incidentally, I actually already have permission from Walter to
 redistribute DMD; a professor at uni wanted to take a peek so I put
 together an installer.)
 
 As for using an installer "tool", I don't think that's really
 applicable for something like this.  I say write it in D because
 otherwise we'll have people saying that D sucks because we don't use
 it.
 


 will cut the effort to produce this by like 90%. I'd rather see that
 time spent on just about anything rather than using D just so we can
 say we do.
 


 such a tool does exist, then fantastic; let's use that.
 


Anything worth looking at will do the only things I think a DMD installer 
should do.

Jun 28 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

BCS wrote:
 I guess it's just that an installer that needs anything else (including
 an internet connection) to install seems utterly pointless to me. In my
 book an installer is firstly the data to be installed and secondly a
 tool to configure it. When I download an installer, I want to know that
 it will work where ever and when ever I have that file. Even if Walter
 decides to shutdown digitalmars so he can go off and become a monk.


One thing I should probably have made explicit: the Cygwin setup program
downloads all packages as you request them, *and keeps a local cache*.

Let's say you wanted to install D on a machine with no 'net access.
Grab the installer, put it on a 'net-connected machine, select what you
want and check a "download only" option.  Then you can archive the whole
directory for later.

 Anything worth looking at will do the only things I think a DMD
 installer should do.


The only reason I don't suggest putting together a simple installer
is... I just don't see the point.  Lacking any sort of "bundle-ready"
IDE or documentation, what would it do?

I suppose it'd be trivial to knock together something that just extracts
the archive and sets the PATH.  I just have a very hard time accepting
that there exist "programmers" THAT lazy and/or stupid.

Oh to hell with it.

Jun 29 2009

BCS <none anon.com> writes:

Hello Daniel,


 One thing I should probably have made explicit: the Cygwin setup
 program downloads all packages as you request them, *and keeps a local
 cache*.
 
 Let's say you wanted to install D on a machine with no 'net access.
 Grab the installer, put it on a 'net-connected machine, select what you
 want and check a "download only" option.  Then you can archive the whole
 directory for later.


A "bundle everything" installer can't be that much harder to build, how about 
make one of each?

 The only reason I don't suggest putting together a simple installer
 is... I just don't see the point.  Lacking any sort of "bundle-ready"
 IDE or documentation, what would it do?


I can easily see some pointy haired boss forbidding the use of something 
because the "installer" is a zip file.

 I suppose it'd be trivial to knock together something that just
 extracts the archive and sets the PATH.  I just have a very hard time
 accepting that there exist "programmers" THAT lazy and/or stupid.


I have a hard time believing that there is an upper (or lower) bound on how 
lazy and/or stupid people can be, regardless of what they do for a living.

Jun 29 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

BCS wrote:
 Hello Daniel,
 
 
 One thing I should probably have made explicit: the Cygwin setup
 program downloads all packages as you request them, *and keeps a local
 cache*.

 Let's say you wanted to install D on a machine with no 'net access.
 Grab the installer, put it on a 'net-connected machine, select what you
 want and check a "download only" option.  Then you can archive the whole
 directory for later.


 A "bundle everything" installer can't be that much harder to build, how
 about make one of each?


Oh, it'd definitely be easier.  *However*

Daniel Keep wrote:
 But technically, the people who download it then can't redistribute
 it. I just think it's simpler to have the installer download the zip
 file itself and avoid the problem in its entirety.


One big download is technically simpler, but not legally.  :P

I don't want to have to put up a big "Download D!" link and then have a
block of small print below it saying "By the way, you're not legally
allowed to redistribute this installer, host it anywhere, mirror it,
etc." and then have to explain why.

For reference, here's the applicable snippet of the license:

 The Software is copyrighted and comes with a single user license,
 and may not be redistributed. If you wish to obtain a redistribution
 license, please contact Digital Mars.


Maybe we could work out a license with Walter for the installers which
allows them to be arbitrarily redistributed provided the installer is
unmodified?  Then we can show the DMD license itself as part of the
install process.

 The only reason I don't suggest putting together a simple installer
 is... I just don't see the point.  Lacking any sort of "bundle-ready"
 IDE or documentation, what would it do?


 I can easily see some pointy haired boss forbidding the use of something
 because the "installer" is a zip file.
 
 I suppose it'd be trivial to knock together something that just
 extracts the archive and sets the PATH.  I just have a very hard time
 accepting that there exist "programmers" THAT lazy and/or stupid.


 I have a hard time believing that there is an upper (or lower) bound on
 how lazy and/or stupid people can be, regardless of what they do for a
 living.


I know, I know.

*sigh*  I've already started trying to whip the language docs into shape
for building into a CHM.  I found CyberShadow's CHM stuff
<http://thecybershadow.net/d/docs/> which will make a good starting point.

I want to remove the cruft around the content (such as the DigitalMars
navigation) and give it a minor facelift (look at some nicer fonts,
maybe a little bit of visual bling).

I also want to look at making two versions: a language+phobos help file
and a language+tango help file.  I also want to find a tutorial to
include with it.

Jun 30 2009

BCS <none anon.com> writes:

Hello Daniel,

 BCS wrote:
 
 Hello Daniel,
 
 One thing I should probably have made explicit: the Cygwin setup
 program downloads all packages as you request them, *and keeps a
 local cache*.
 
 Let's say you wanted to install D on a machine with no 'net access.
 Grab the installer, put it on a 'net-connected machine, select what
 you
 want and check a "download only" option.  Then you can archive the
 whole
 directory for later.


 how about make one of each?
 


 
 Daniel Keep wrote:
 
 But technically, the people who download it then can't redistribute
 it. I just think it's simpler to have the installer download the zip
 file itself and avoid the problem in its entirety.
 




I am assuming that Walter would host the file and there would be nothing 
stopping him from distributing such a file.

 I don't want to have to put up a big "Download D!" link and then have
 a block of small print below it saying "By the way, you're not legally
 allowed to redistribute this installer, host it anywhere, mirror it,
 etc." and then have to explain why.
 


I would assume most non FOSS stuff can't legally be redistributed even if 
it can be downloaded at no cost.

 For reference, here's the applicable snippet of the license:
 
 The Software is copyrighted and comes with a single user license, and
 may not be redistributed. If you wish to obtain a redistribution
 license, please contact Digital Mars.
 


 allows them to be arbitrarily redistributed provided the installer is
 unmodified?  Then we can show the DMD license itself as part of the
 install process.


I strongly suspect that Walter would be just fine with that. Particularly 
if it's limited to an ad-hoc bases (e.g. download it and e-mail it around 
the office)


 *sigh*  I've already started trying to whip the language docs into
 shape for building into a CHM.  I found CyberShadow's CHM stuff
 <http://thecybershadow.net/d/docs/> which will make a good starting
 point.


sweet
 
 I want to remove the cruft around the content (such as the DigitalMars
 navigation) and give it a minor facelift (look at some nicer fonts,
 maybe a little bit of visual bling).


The Phobos repo on dsource contains the DDoc source for the full docs, you 
should be able to patch its ddoc.conf file to generate whatever you want. 
As a fridge benefit, it would make updating the results to new versions more 
automatable.

Jun 30 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Daniel Keep escribi�:
 
 BCS wrote:
 I guess it's just that an installer that needs anything else (including
 an internet connection) to install seems utterly pointless to me. In my
 book an installer is firstly the data to be installed and secondly a
 tool to configure it. When I download an installer, I want to know that
 it will work where ever and when ever I have that file. Even if Walter
 decides to shutdown digitalmars so he can go off and become a monk.


 One thing I should probably have made explicit: the Cygwin setup program
 downloads all packages as you request them, *and keeps a local cache*.
 
 Let's say you wanted to install D on a machine with no 'net access.
 Grab the installer, put it on a 'net-connected machine, select what you
 want and check a "download only" option.  Then you can archive the whole
 directory for later.
 
 Anything worth looking at will do the only things I think a DMD
 installer should do.


 The only reason I don't suggest putting together a simple installer
 is... I just don't see the point.  Lacking any sort of "bundle-ready"
 IDE or documentation, what would it do?
 
 I suppose it'd be trivial to knock together something that just extracts
 the archive and sets the PATH.  I just have a very hard time accepting
 that there exist "programmers" THAT lazy and/or stupid.
 
 Oh to hell with it.


It's not about being lazy!

If you can double click a file and it does all the things for you, why 
would you want to do it manually?

It's actually a programmers philosophy. If you can write a program that 
does the things for you, instead of you having to do them manually, why not?

Jun 30 2009

Daniel Keep <daniel.keep.lists gmail.com> writes:

Ary Borenszweig wrote:
 Daniel Keep escribi�:
 BCS wrote:
 I suppose it'd be trivial to knock together something that just extracts
 the archive and sets the PATH.


 In case you didn't notice, I already did that:
 
 http://downloads.dsource.org/projects/descent/dinstaller/
 
 I don't know why nobody said anything or started talking about how it
 should be continued. Maybe people like to discuss more and do less. :-P


I didn't mention it because I object to the lack of proper
capitalisation in the name; it must be rewritten!

(Just kidding.)

In that specific sentence, I was talking about one that included the DMD
archive.  The previous times I talked about downloading the archive, it
was in the context of a more complex installer.

Jun 30 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Daniel Keep escribi�:
 
 Ary Borenszweig wrote:
 Daniel Keep escribi�:
 BCS wrote:
 I suppose it'd be trivial to knock together something that just extracts
 the archive and sets the PATH.



 http://downloads.dsource.org/projects/descent/dinstaller/

 I don't know why nobody said anything or started talking about how it
 should be continued. Maybe people like to discuss more and do less. :-P


 I didn't mention it because I object to the lack of proper
 capitalisation in the name; it must be rewritten!
 
 (Just kidding.)


lol :)

I always have troubles with naming things for D:

Dinstaller?
DInstaller?
dinstaller?
DeeInstaller?

Grrr...

 In that specific sentence, I was talking about one that included the DMD
 archive.  The previous times I talked about downloading the archive, it
 was in the context of a more complex installer.


The nice thing about the installer downloading it is that 
digitalmars.com could provide a page that links automatically to the 
latest zips, and the installer could point to that address.

Jun 30 2009

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

On Sun, 28 Jun 2009 08:24:59 +0300, Daniel Keep  
<daniel.keep.lists gmail.com> wrote:

 As for using an installer "tool", I don't think that's really applicable
 for something like this.  I say write it in D because otherwise we'll
 have people saying that D sucks because we don't use it.  *sigh*


I've thought a bit about this and I agree. There isn't really much  
complicated stuff going on during the installation of a Windows  
application - copy files, create uninstaller, add entry to the Add/Remove  
Programs list... Using a generic install system is very likely to get in  
our way as soon as we get past the "download and unpack DMD" phase,  
because our goal isn't exactly typical, and we need to take varying  
approaches to maintain different packages. Installer creators will get us  
a user interface consistent with other installers and that registry  
setting, but customizing the install process will require using plugin  
DLLs or helper programs (or using severely limited scripting languages),  
which could get really messy really fast.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jun 28 2009

BCS <none anon.com> writes:

Hello Vladimir,

 Therefore, I was thinking that the
 installer could  download and install components (libraries, text
 editors/IDEs or plugins  for them, build tools) from the web if the
 user ticks some corresponding  checkboxes.


libs? maybe. Tools? No! I hate "installeres" that go out and download what 
they are supposed to install. For one thing it make it really hard to archive 
your toolchain.

 
 Further ideas:
 * adjust PATH to include DMD and any selected build tools


Duh :)

 * DSSS "net install" integration? (show a checkbox list of libraries)


that could work

 As for the installer system: I'm familiar with NSIS and InnoSetup,
 both  are open-source. NSIS is extensible and can thus download files
 from the  Internet, but AFAIK InnoSetup can't (even though it has a
 more flexible  scripting language). Windows Installer is also used by
 some open-source  software like TortoiseSVN.


I've only ever looked at InnoSetup.

Jun 27 2009

Lester L. Martin II <lestermartin92 gmail.com> writes:

Jesse Phillips Wrote:

 On Sun, 28 Jun 2009 03:43:16 +0300, Vladimir Panteleev wrote:
 
 As recently posted by WB, we should get a Windows installer project
 going. I think we should first discuss what this installer would
 contain, which installer framework to use, etc.


 So, something like the DInstaller project?
 
 http://dsource.org/projects/dinstaller
 
 Never really got a great amount of interest.


That was my project. I stopped for a while out of disinterest and I'm working
on it a bit, just no commits. I was working on something that would help DSSS
net out I think. I haven't finished it yet. If there is any interest please
email me, post here, or in the Dinstaller forum part. I'm not just going to let
it die, I've just got a bit behind is all.

Jun 28 2009

Lester L. Martin II <lestermartin92 gmail.com> writes:

Lester L. Martin II Wrote:

 Jesse Phillips Wrote:
 
 On Sun, 28 Jun 2009 03:43:16 +0300, Vladimir Panteleev wrote:
 
 As recently posted by WB, we should get a Windows installer project
 going. I think we should first discuss what this installer would
 contain, which installer framework to use, etc.


 So, something like the DInstaller project?
 
 http://dsource.org/projects/dinstaller
 
 Never really got a great amount of interest.


 That was my project. I stopped for a while out of disinterest and I'm working
on it a bit, just no commits. I was working on something that would help DSSS
net out I think. I haven't finished it yet. If there is any interest please
email me, post here, or in the Dinstaller forum part. I'm not just going to let
it die, I've just got a bit behind is all.
 


I was a bit skimpy on the projects plan. It's supposed to end up being a D
Installer in D for multiple compiler sets, libraries, and some other stuff and
it would use DSSS net to get all these different things once I completed that
DSSS Net thing. It would end up being like a "package manager" for D because it
could upgrade, downgrade and so much more such as resolve conflicts between
libraries ("No, you are not allowed to install that because it is not going to
work with what you got, can I recommend you X instead, oh, ok you said no, do
you want to install anyway, gosh, you said yes, I'll continue, but don't say I
didn't warn ya"). Of course that type of resolving feature wasn't going to make
it into first release because that's particularly hard. The upgrade feature
would upgrade or fail and not upgrade anything. the downgrade feature is a
"just in case" feature. Of course, most of this is conceptual at the moment,
though I have a lot of the backend of a DSSS net thing written, I have yet to
give it the hooks required to download, and install, and have yet to give it a
simple command line interface.

Jun 28 2009

Lester L. Martin II <lestermartin92 gmail.com> writes:

Vladimir Panteleev Wrote:

 On Sun, 28 Jun 2009 15:44:04 +0300, Lester L. Martin II  
 <lestermartin92 gmail.com> wrote:
 
 I was a bit skimpy on the projects plan. It's supposed to end up being a  
 D Installer in D for multiple compiler sets, libraries, and some other  
 stuff and it would use DSSS net to get all these different things once I  
 completed that DSSS Net thing. It would end up being like a "package  
 manager" for D because it could upgrade, downgrade and so much more such  
 as resolve conflicts between libraries ("No, you are not allowed to  
 install that because it is not going to work with what you got, can I  
 recommend you X instead, oh, ok you said no, do you want to install  
 anyway, gosh, you said yes, I'll continue, but don't say I didn't warn  
 ya"). Of course that type of resolving feature wasn't going to make it  
 into first release because that's particularly hard. The upgrade feature  
 would upgrade or fail and not upgrade anything. the downgrade feature is  
 a "just in case" feature. Of course, most of this is conceptual at the  
 moment, though I have a lot of the backend of a DSSS net thing written,  
 I have yet to give it the hooks required to download, and install, and  
 have yet to give it a simple command line interface.


 Judging by SVN [1] there isn't much to look at at the moment, so I had a  
 look at the XML example [2]. Some questions:
 
 1) Why do you have a list of downloads? Are these supposed to be mirrors?  
 Or does each one represent a version?
 2) What's the difference between package dependencies and download  
 dependencies?
 3) Why are the package dependencies in human-readable format (and include  
 Internet location) rather than reference another package by name?
 4) Same for download dependencies - aren't a package identifier and  
 version sufficient for a dependency declaration?
 5) I don't think installation instructions can be described in only shell  
 commands...
 
 Sorry if that was a very rough draft and your actual design isn't  
 challenged by these questions.
 
 [1]  
 http://dsource.org/projects/dinstaller/browser/trunk/D/Dinstaller%20in%20D
 [2] http://www.dsource.org/projects/dinstaller/wiki/pdesc
 
 -- 
 Best regards,
   Vladimir                          mailto:thecybershadow gmail.com


The naming of the project is probably incorrect (since I didn't really worry
about it compared to the code), a more complete one is (here
http://fsdev.net/repositories/browse/dsss/trunk/backend ) but I haven't merged
some of my changes and besides that, I think those changes were lost in my last
windows crash (since I was on windows then if I'm correct). However, it's a
pretty good starting point. Some of it may need to be updated to latest tango
though. At the moment it's a framework pretty much where the application has 3
layers.. the framework, which is protocol independant, the protocol dependant
stuff (ftp/http/SOMEODDCREATION) that is a basic set of hooks that comply to a
certain function definition and when initing the backend, hook itself into it
to get the stuff over the protocol, and then their is the command line level
which controls managing all this....
http://fsdev.net/repositories/browse/dsss/trunk/backend It's got the backend
pretty much finished if I remember correctly and I had started works on the
midend hooks for http and ftp, and then lost that work. It shouldn't be super
hard if I remember correctly and it should also all compile (if I remember
correctly).

Jun 28 2009

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

On Sun, 28 Jun 2009 15:44:04 +0300, Lester L. Martin II  
<lestermartin92 gmail.com> wrote:

 I was a bit skimpy on the projects plan. It's supposed to end up being a  
 D Installer in D for multiple compiler sets, libraries, and some other  
 stuff and it would use DSSS net to get all these different things once I  
 completed that DSSS Net thing. It would end up being like a "package  
 manager" for D because it could upgrade, downgrade and so much more such  
 as resolve conflicts between libraries ("No, you are not allowed to  
 install that because it is not going to work with what you got, can I  
 recommend you X instead, oh, ok you said no, do you want to install  
 anyway, gosh, you said yes, I'll continue, but don't say I didn't warn  
 ya"). Of course that type of resolving feature wasn't going to make it  
 into first release because that's particularly hard. The upgrade feature  
 would upgrade or fail and not upgrade anything. the downgrade feature is  
 a "just in case" feature. Of course, most of this is conceptual at the  
 moment, though I have a lot of the backend of a DSSS net thing written,  
 I have yet to give it the hooks required to download, and install, and  
 have yet to give it a simple command line interface.


Judging by SVN [1] there isn't much to look at at the moment, so I had a  
look at the XML example [2]. Some questions:

1) Why do you have a list of downloads? Are these supposed to be mirrors?  
Or does each one represent a version?
2) What's the difference between package dependencies and download  
dependencies?
3) Why are the package dependencies in human-readable format (and include  
Internet location) rather than reference another package by name?
4) Same for download dependencies - aren't a package identifier and  
version sufficient for a dependency declaration?
5) I don't think installation instructions can be described in only shell  
commands...

Sorry if that was a very rough draft and your actual design isn't  
challenged by these questions.

[1]  
http://dsource.org/projects/dinstaller/browser/trunk/D/Dinstaller%20in%20D
[2] http://www.dsource.org/projects/dinstaller/wiki/pdesc

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jun 28 2009

Lutger <lutger.blijdestijn gmail.com> writes:

Vladimir Panteleev wrote:

 As recently posted by WB, we should get a Windows installer project going.
 I think we should first discuss what this installer would contain, which
 installer framework to use, etc.
 
 In my opinion, the Windows installer's goal is somewhat different than a
 Linux installer. I've heard many people say that they'd love a simple
 installer that installs them everything including a build tool, IDE,
 debugger, etc., so perhaps it should allow installing more than just the
 barebones DMD. However, we don't want to include things that many people
 won't use either. Therefore, I was thinking that the installer could
 download and install components (libraries, text editors/IDEs or plugins
 for them, build tools) from the web if the user ticks some corresponding
 checkboxes.
 
 Further ideas:
 * support Windows' "change" option in Add/Remove Programs to allow
 removing, reinstalling and updating components
 * when installing an editor, associate .d files with it
 * adjust PATH to include DMD and any selected build tools
 * adjust DMD search paths to point to any additional libraries (Tango,
 DSSS etc.)
 * DSSS "net install" integration? (show a checkbox list of libraries)



Wouldn't it be sweet to go further and use dsss as that part of the 
installer which handles the libraries or more? There's probably a good bit 
of useful code in there, or even better dsss could be updated as required by 
the installer project. That will leverage dsss user base and revive dsss at 
once. Plus the way dsss works, it makes it easy to extend the list of 
components in the future.

Jun 28 2009

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

On Sun, 28 Jun 2009 10:45:06 +0300, Lutger <lutger.blijdestijn gmail.com>  
wrote:

 Wouldn't it be sweet to go further and use dsss as that part of the
 installer which handles the libraries or more? There's probably a good  
 bit
 of useful code in there, or even better dsss could be updated as  
 required by
 the installer project. That will leverage dsss user base and revive dsss  
 at
 once. Plus the way dsss works, it makes it easy to extend the list of
 components in the future.


I actually wanted to look at that as I heard DSSS could actually install  
DMD and Tango, but it looks like DSSS's sources mirror (  
http://dsss.brainsware.org/sources ) has been down for a while now :/

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jun 28 2009

Robert Clipsham <robert octarineparrot.com> writes:

On 28/6/09 01:43, Vladimir Panteleev wrote:
 As recently posted by WB, we should get a Windows installer project
 going. I think we should first discuss what this installer would
 contain, which installer framework to use, etc.

 In my opinion, the Windows installer's goal is somewhat different than a
 Linux installer. I've heard many people say that they'd love a simple
 installer that installs them everything including a build tool, IDE,
 debugger, etc., so perhaps it should allow installing more than just the
 barebones DMD. However, we don't want to include things that many people
 won't use either. Therefore, I was thinking that the installer could
 download and install components (libraries, text editors/IDEs or plugins
 for them, build tools) from the web if the user ticks some corresponding
 checkboxes.

 Further ideas:
 * support Windows' "change" option in Add/Remove Programs to allow
 removing, reinstalling and updating components
 * when installing an editor, associate .d files with it
 * adjust PATH to include DMD and any selected build tools
 * adjust DMD search paths to point to any additional libraries (Tango,
 DSSS etc.)
 * DSSS "net install" integration? (show a checkbox list of libraries)

 Going further with this idea, we could remove DMD itself from the
 installer and allow the user to install DMD1/DMD2 as a component, thus
 creating a "meta-installer" to manage the D toolchain.

 As for the installer system: I'm familiar with NSIS and InnoSetup, both
 are open-source. NSIS is extensible and can thus download files from the
 Internet, but AFAIK InnoSetup can't (even though it has a more flexible
 scripting language). Windows Installer is also used by some open-source
 software like TortoiseSVN.


I guess if we want to do this properly, a full install wizard should be 
there, allowing you to simply click 'Next' to get a full working 
toolchain: Compiler (probably dmd), Build tool (one of bu[il]d, rebuild, 
xfbuild), and a base set of libraries. There should also be an advanced 
option to pick between D1/2, pick compiler, build tool, libraries, 
phobos/tango etc. There could also be an option to install an 
ide/debugger which a lot of people will find useful.

Jun 28 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Ary Borenszweig wrote:
 Walter Bright wrote:
 For the initial version, I'd be happy if it downloaded the zip file, 
 unzipped it, and set the path.


 Here:
 
 http://downloads.dsource.org/projects/descent/dinstaller/
 
 (I just put it there because I didn't know where else)
 
 Maybe this can be used as the initial source code for the project...


Meh, dmd doesn't seem to work if the path has spaces. Also I forgot to 
download dmc.zip.

Now the installer should work ok (it suggests "C:\D" as the default 
installation dir).

Jun 29 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Walter Bright wrote:
 Ary Borenszweig wrote:
 Walter Bright wrote:
 For the initial version, I'd be happy if it downloaded the zip file, 
 unzipped it, and set the path.


 Here:

 http://downloads.dsource.org/projects/descent/dinstaller/

 (I just put it there because I didn't know where else)

 Maybe this can be used as the initial source code for the project...


 Thanks. But I am totally unfamiliar with nsi files, etc. Is there a 
 makefile or build.bat file?


Even if there were one, you'd need to install NSIS to compile them. It's 
a language by itself.

Why do you need to compile it? There's an exe there. :)

Jun 30 2009

BCS <ao pathlink.com> writes:

Reply to Ary,

 Walter Bright wrote:
 
 Ary Borenszweig wrote:
 
 Walter Bright wrote:
 
 For the initial version, I'd be happy if it downloaded the zip
 file, unzipped it, and set the path.
 


 
 http://downloads.dsource.org/projects/descent/dinstaller/
 
 (I just put it there because I didn't know where else)
 
 Maybe this can be used as the initial source code for the project...
 


 makefile or build.bat file?
 


 It's a language by itself.
 
 Why do you need to compile it? There's an exe there. :)
 


So he can make generateing new versions part of the build process.

Jun 30 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

BCS wrote:
 Reply to Ary,
 
 Walter Bright wrote:

 Ary Borenszweig wrote:

 Walter Bright wrote:

 For the initial version, I'd be happy if it downloaded the zip
 file, unzipped it, and set the path.



 http://downloads.dsource.org/projects/descent/dinstaller/

 (I just put it there because I didn't know where else)

 Maybe this can be used as the initial source code for the project...


 makefile or build.bat file?


 It's a language by itself.

 Why do you need to compile it? There's an exe there. :)


 So he can make generateing new versions part of the build process.


But for that the only thing he need to do is to tell us URLs for the 
latests zip files to download. Then the installer points to those URLs 
and it never needs to change.

Of course he'll need to repoint the URLs to the latest zip files.

Jun 30 2009

BCS <ao pathlink.com> writes:

Reply to Ary,

 BCS wrote:
 
 Reply to Ary,
 
 Walter Bright wrote:
 
 Ary Borenszweig wrote:
 
 Walter Bright wrote:
 
 For the initial version, I'd be happy if it downloaded the zip
 file, unzipped it, and set the path.
 


 
 http://downloads.dsource.org/projects/descent/dinstaller/
 
 (I just put it there because I didn't know where else)
 
 Maybe this can be used as the initial source code for the
 project...
 


 makefile or build.bat file?
 


 It's a language by itself.
 
 Why do you need to compile it? There's an exe there. :)
 


 


 latests zip files to download.


Oh, it's one of the kind of installer I have no use for. Sorry missed that 
bit.

Given that this is just good enought "for the initial version", maybe he's 
thinking it as a base for an installer that actually has the needed data 
in it.

Jun 30 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

BCS wrote:
 Reply to Ary,
 
 BCS wrote:

 Reply to Ary,

 Walter Bright wrote:

 Ary Borenszweig wrote:

 Walter Bright wrote:

 For the initial version, I'd be happy if it downloaded the zip
 file, unzipped it, and set the path.



 http://downloads.dsource.org/projects/descent/dinstaller/

 (I just put it there because I didn't know where else)

 Maybe this can be used as the initial source code for the
 project...


 makefile or build.bat file?


 It's a language by itself.

 Why do you need to compile it? There's an exe there. :)




 latests zip files to download.


 Oh, it's one of the kind of installer I have no use for. Sorry missed 
 that bit.


Why not?

 Given that this is just good enought "for the initial version", maybe 
 he's thinking it as a base for an installer that actually has the needed 
 data in it.


Ah, ok. In that case the scripts needs to be modified to include the 
zips in it instead of downloading them. But in either case he'll need to 
run the nsis compiler.

Jun 30 2009

BCS <ao pathlink.com> writes:

Reply to Ary,

 But for that the only thing he need to do is to tell us URLs for the
 latests zip files to download.
 


 that bit.
 




I have no like for installers that don't contain (in the installer I download) 
the data they are supposed to install (I'll use them if there is no other 
way to install the program). I've already stated my reasons several times 
in this thread, but in short: I want an installer that has no dependencies 
(particularly no net dependencies) other than things like Windows (tm). I 
want to be able to archive it and know it will install the same version later, 
no matter what the rest of the world does. Most of the other uses being tossed 
about for an installer I would rather do via something else (like SVN).

Jun 30 2009

"Nick Sabalausky" <a a.a> writes:

"BCS" <ao pathlink.com> wrote in message 
news:78ccfa2d42b718cbc79c3bb7b06a news.digitalmars.com...
 Reply to Ary,

 But for that the only thing he need to do is to tell us URLs for the
 latests zip files to download.


 that bit.




 I have no like for installers that don't contain (in the installer I 
 download) the data they are supposed to install (I'll use them if there is 
 no other way to install the program). I've already stated my reasons 
 several times in this thread, but in short: I want an installer that has 
 no dependencies (particularly no net dependencies) other than things like 
 Windows (tm). I want to be able to archive it and know it will install the 
 same version later, no matter what the rest of the world does. Most of the 
 other uses being tossed about for an installer I would rather do via 
 something else (like SVN).


Yea, this is why I'm convinced that, at least at some point, we'll want to 
have both kinds available, because there are a lot of people on both sides 
of that fence (I'm somewhere in between, fwiw).

Jun 30 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Walter Bright wrote:
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Thanks. But I am totally unfamiliar with nsi files, etc. Is there a 
 makefile or build.bat file?


 Even if there were one, you'd need to install NSIS to compile them. 
 It's a language by itself.

 Why do you need to compile it? There's an exe there. :)


 Yeah, well, it needs to be rebuilt for every new release.
 
 Why does it need to set registry keys?


To make uninstall available from the add/remove programs in Windows.

Also to remember the installation language (just for the UI of the 
installer), although English is the only language for now, but it's easy 
to add another ones (supporting multiple languages in the installer 
makes it look more professional also).

Jun 30 2009

Walter Bright <newshound1 digitalmars.com> writes:

Ary Borenszweig wrote:
 Walter Bright wrote:
 Why does it need to set registry keys?


 To make uninstall available from the add/remove programs in Windows.
 
 Also to remember the installation language (just for the UI of the 
 installer), although English is the only language for now, but it's easy 
 to add another ones (supporting multiple languages in the installer 
 makes it look more professional also).


Makes sense. Can you email me the makefile or build.bat? I'd say check 
it in, but the project still hasn't been created.

Jun 30 2009

Ary Borenszweig <ary esperanto.org.ar> writes:

Walter Bright wrote:
 Ary Borenszweig wrote:
 Walter Bright wrote:
 Why does it need to set registry keys?


 To make uninstall available from the add/remove programs in Windows.

 Also to remember the installation language (just for the UI of the 
 installer), although English is the only language for now, but it's 
 easy to add another ones (supporting multiple languages in the 
 installer makes it look more professional also).


 Makes sense. Can you email me the makefile or build.bat? I'd say check 
 it in, but the project still hasn't been created.


I've updated the installer:

http://downloads.dsource.org/projects/descent/dinstaller/

I've uploaded the make_dinstaller.bat file, which just contains:

makensis dinstaller.nsi

You'll need NSIS for this, and it must be in your path (or change the 
bat to include the absolute path, and that's it).

When generating the installer you can choose whether it will download 
the zip files (and where from), or whether it will contain the zip files 
in it. If you open the dinstaller.nsi you'll see this:

;--------------------------------------------------------
; Defines
;--------------------------------------------------------

; Download zip from website, or include the compressed zip?
!define Download

; If Download, the urls of the dmd.zip and dmc.zip
!define DownloadDmdZipUrl "http://ftp.digitalmars.com/dmd.1.030.zip"
!define DownloadDmcZipUrl "http://ftp.digitalmars.com/dmc.zip"

; If not Download, the paths of dmd.zip and dmc.zip
!define DmdZipPath "dmd.1.030.zip"
!define DmcZipPath "dmc.zip"

---

I think that's pretty self explanatory. :)

Both DmdZipPath and DmcZipPath may be absolute.

You can also declare these defines when invoking makensis, like:

makensis /DDownloadDmdZipUrl=whatever

but you'll need to remove the defines from the nsi file.

I hope that helps. :)

Jun 30 2009

Stewart Gordon <smjg_1998 yahoo.com> writes:

Vladimir Panteleev wrote:
<snip>
 In my opinion, the Windows installer's goal is somewhat different than a 
 Linux installer. I've heard many people say that they'd love a simple 
 installer that installs them everything including a build tool, IDE, 
 debugger, etc., so perhaps it should allow installing more than just the 
 barebones DMD.


Perhaps?  Definitely, if you're going to bother with an installer at 
all.  At least, I can't see any point in having an installer for 
barebones DMD.

 However, we don't want to include things that many people 
 won't use either. Therefore, I was thinking that the installer could 
 download and install components (libraries, text editors/IDEs or plugins 
 for them, build tools) from the web if the user ticks some corresponding 
 checkboxes.


How is the set of libraries that your installer can install going to be 
maintained?  Will anyone be able to contribute?

The ideal, however, is to have it so that the user can paste in the URL 
of any D library and the installer'll install it.  However, until and 
unless we can standardise how to package a library for download, the 
user would have to guess whether the installer supports the particular 
library's way of doing it.

 Further ideas:
 * support Windows' "change" option in Add/Remove Programs to allow 
 removing, reinstalling and updating components
 * when installing an editor, associate .d files with it
 * adjust PATH to include DMD and any selected build tools
 * adjust DMD search paths to point to any additional libraries (Tango, 
 DSSS etc.)



Why not install all third-party libraries under a common base path?

Stewart.

Jun 28 2009

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

On Sun, 28 Jun 2009 23:38:27 +0300, Stewart Gordon <smjg_1998 yahoo.com>  
wrote:

 How is the set of libraries that your installer can install going to be  
 maintained?  Will anyone be able to contribute?


Since this is a community project, it's important not to make any  
component dependent on a single party. I was thinking of something like  
DSSS's system, where package maintainers can register and maintain  
installation/uninstallation "recipes" (not unlike GoboLinux).

 The ideal, however, is to have it so that the user can paste in the URL  
 of any D library and the installer'll install it.  However, until and  
 unless we can standardise how to package a library for download, the  
 user would have to guess whether the installer supports the particular  
 library's way of doing it.


We can do this for libraries containing dsss.conf files.

 Why not install all third-party libraries under a common base path?


Some libraries are packaged with documentation, examples, etc. with the  
actual source in a subdirectory. On my system I resolve this with a  
"packages" directory (containing library packages with the directory  
structure intact) and an "import" directory, which contains symlinks to  
the libraries' source directories. We can't do this since some users still  
use FAT32.

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jun 28 2009

"Nick Sabalausky" <a a.a> writes:

"Vladimir Panteleev" <thecybershadow gmail.com> wrote in message 
news:op.uv86plz3m02fvl cybershadow...
 Some libraries are packaged with documentation, examples, etc. with the 
 actual source in a subdirectory. On my system I resolve this with a 
 "packages" directory (containing library packages with the directory 
 structure intact) and an "import" directory, which contains symlinks to 
 the libraries' source directories. We can't do this since some users still 
 use FAT32.


Do you mean to imply NTFS can do this? How? Possible on Win, too? I'm a big 
Windows guy, but symlinks are one of the things I really miss from the times 
I've used Unix.

Jun 28 2009

Stewart Gordon <smjg_1998 yahoo.com> writes:

Vladimir Panteleev wrote:
<snip>
 Since this is a community project, it's important not to make any 
 component dependent on a single party. I was thinking of something like 
 DSSS's system, where package maintainers can register and maintain 
 installation/uninstallation "recipes" (not unlike GoboLinux).


I guess I'll just have to look into this DSSS thing sometime.

<snip>
 Why not install all third-party libraries under a common base path?


 Some libraries are packaged with documentation, examples, etc. with the 
 actual source in a subdirectory. On my system I resolve this with a 
 "packages" directory (containing library packages with the directory 
 structure intact) and an "import" directory, which contains symlinks to 
 the libraries' source directories. We can't do this since some users 
 still use FAT32.


That begs the question of whether keeping the directory structure intact 
at all costs is something we really want to do.  ISTM part of the 
process of installing something is putting the parts of a package in 
their respective right places.

Is there a plan for how to deal with modules that are duplicated between 
library packages?

Stewart.

Jun 30 2009

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

On Mon, 29 Jun 2009 00:38:35 +0300, Nick Sabalausky <a a.a> wrote:

 "Vladimir Panteleev" <thecybershadow gmail.com> wrote in message
 news:op.uv86plz3m02fvl cybershadow...
 Some libraries are packaged with documentation, examples, etc. with the
 actual source in a subdirectory. On my system I resolve this with a
 "packages" directory (containing library packages with the directory
 structure intact) and an "import" directory, which contains symlinks to
 the libraries' source directories. We can't do this since some users  
 still
 use FAT32.


 Do you mean to imply NTFS can do this? How? Possible on Win, too? I'm a  
 big
 Windows guy, but symlinks are one of the things I really miss from the  
 times
 I've used Unix.


NTFS supports 'junction points' which allow you to create something like  
directory symlinks that point to other local drives or directories. The  
NTFS version introduced in Windows Vista has, additionally, "real"  
symlinks, in that you can use them to link to files or directories on  
network drives.

This is one feature that hasn't much of a standard UI implementation.  
Versions before Vista didn't even have a standard command-line tool to  
create them, users had to use 3rd-party software. Vista and newer have a  
"mklink" command. Personally I use the excellent, now-open-source FAR  
manager [1], which had the ability to create various NTFS links for a long  
time now.

[1] http://www.farmanager.com/opensource.php

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jun 28 2009

"Vladimir Panteleev" <thecybershadow gmail.com> writes:

On Sun, 28 Jun 2009 08:23:11 +0300, BCS <none anon.com> wrote:

 libs? maybe. Tools? No! I hate "installeres" that go out and download  
 what they are supposed to install. For one thing it make it really hard  
 to archive your toolchain.


This would imply that you (and other users) would have to download the  
entire toolchain every time one tool updates.

Also I think it's pretty clear that Walter would rather have the installer  
download DMD rather than include it.

What's wrong with compressing your entire D folder, including all settings?

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com

Jun 28 2009

BCS <none anon.com> writes:

Hello Vladimir,

 On Sun, 28 Jun 2009 08:23:11 +0300, BCS <none anon.com> wrote:
 
 libs? maybe. Tools? No! I hate "installeres" that go out and download
 what they are supposed to install. For one thing it make it really
 hard  to archive your toolchain.
 


 entire toolchain every time one tool updates.


The same people who want to archive there tool chains will pick one version 
and stick with it. That's the point of archiving it; so that you can keep 
a copy of that verion around.

That said, I'd be fine with an installer that offers to go find the latest 
versions. Or replace the whole thing with a list of links to installers for 
each component.

 
 Also I think it's pretty clear that Walter would rather have the
 installer download DMD rather than include it.


I think what is clear is that  Walter wants DMD to get distributed from the 
digitalmars site. I suspect if we get a setup working where he can generate 
the installer by running a single script that he would have no issue putting 
the result up there.

 
 What's wrong with compressing your entire D folder, including all
 settings?


For me? Nothing. But if that's the option, I'll just skip the installer all 
together and just download dmd.*.zip

Jun 28 2009