Ported update.sh to D which will make it easier to run on Windows/OS X also #158
Conversation
|
This requires some additional work:
There's also significant tactical work you need to do on the sources. I'll make some notes. |
| @@ -0,0 +1,184 @@ | |||
| module scriptutil; | |||
| import core.sys.posix.unistd:geteuid; | |||
|
that's what I got for now |
|
Thanks, Andrei. I am honoured to be destroyed, and will make the changes you suggest. Laeeth. Sent from my iPad
|
|
Btw just as some background - I started learning to code when I was ten (1983) but pursued hedge fund money management as a career. I need to refresh my skills to develop some big data ideas. So many of the developments that took place whilst I was busy doing other things passed me by, and I have spent the past year as a sabbatical catching up a little. But practice makes better, and so does good critique and I thank you for the latter. Laeeth. Sent from my iPad
|
|
Awesome, thanks. FWIW your style is totally fine, just a bit different from the usual in this codebase. |
|
Thanks. I incorporated your suggestions - hope that is okay now. I haven't yet been able to test on Windows as I am rebuilding my VM and might be a couple of days before I have time. So in the meantime I changed posix.mak but didn't want to touch the windows makefile in case doing so broke the whole build. |
|
Before too much work is expended here, I'm going to plug my project again: https://github.com/CyberShadow/Digger It does almost all that this small script does, and much more. Crucially, it obtains all the dependencies needed to build D on Windows - even Visual Studio components for Win64 builds - and installs them in a directory, without affecting the host system. There is also DVM, which doesn't download D but knows how to build and install downloaded D source. I know Andrei knows about Digger, and I've posted a link to the forum thread, so I'd like to question the reason for spending efforts on solved problems. |
|
I had a chat with Vladimir on irc earlier. I didn't know about Digger before, and it does look nice, and it is easy enough to use. I don't think it's a terrible thing to have choices in build/fetch tools, and it is good to have the option of a minimal tool because less brittle and easy to fix. (Nassim Taleb's antifragility). But I will leave it to you. A basic README.MD is in the repo, although my markup knowledge is very basic, and it needs a slight tidyup. The other changes you asked for have been incorporated. |
|
@CyberShadow I'm putting the nightly build together for asm.dlang.org. I used update.sh to download and update and build but I can switch to Digger. I have tried to use digger before but I really didn't like using a browser to connect to it. I believe you can also use the command line but that kinda turned me off so I moved on to other things. However, I do want the setup the nightly build the right way so I'm asking for your advice on this. Which tool should we use? update.sh? Digger? Dvm? and why? Thanks. |
|
|
||
| // Take care of the command line arguments | ||
| writefln("* fetchdlang: a tool for building and maintaining the dlang toolchain from github"); | ||
| foreach(arg; args[1 .. $]) |
There was a problem hiding this comment.
Were you not able to use std.getopt for this?
There was a problem hiding this comment.
honestly, as I wrote it, I sort of clenched my teeth and forced myself to choose the path of a line of line translation rather than a write the functionality from scratch path. if I were writing from scratch, I would also have made as much as possible data rather than hard coding it - so you have a json table of what you need to do. but it is harder to understand, and harder to see what it is doing that way.
On the one hand, the reason to have done this is because it is appealing to have a native code tool and to eat your own dogfood. On the other everything that goes in here is somewhat a showcase, so it makes sense to do things as elegantly as possible.
I am happy to change if people feel strongly about it.
Wrt digger vs a simple little tool, I wasn't aware of digger, and it is beautiful, like Vladimir's other projects. It is a philosophical choice about simple tools that do one thing versus powerful tools that unavoidably are more complex and intimidating. I do not think it hurts to give people a choice, because of the compounding of complexity problem when you are new to a domain. I think thtat's why Andrei was excited about update.sh - his focus being to make it easy and unintimidating for new developers to get involved, and because small initial frictions have large consequences.
Anyway - I leave it to you to decide.
Laeeth.
The web interface is a completely separate program built on top of the command-line "core".
At last year's DConf, Andrei told me we should get Digger into the D-P-L.org repository. If he still means it, then it could probably replace update.sh. |
|
Good to know the web interface is separate. I'll look into it again. |
|
@marler8997 BTW, would you be interested in looking at DPaste as well? It is in dire need of a maintainer, and I have my hands full already unfortunately. |
|
Sure. Email me the details, what needs to be done. |
|
On a related topic, @CyberShadow could you please check the readme for https://github.com/Dicebot/TestDlangAggregated and say what do you think about the design described there? It has rather different goals from https://bitbucket.org/cybershadow/d but still seems very relevant to your work. |
|
Sure:
Also people will need a D compiler to build D anyway (ddmd).
Git 1.8.2 added the ability to track branches in submodules.
This may make using tools such as rdmd or dub difficult. Something like what dvm does might be better. Right now I'm working on an "install" command for digger, alongside an "uninstall" command - with caching, you could use it as a dvm replacement. But for a simple "just get me on my feet" tool, this might be the simplest solution.
Care to go into more detail here? |
I have experimented with that feature. It doesn't work as one would expect it to work - git still stores specific commit hash. Only difference with "normal" submodule seems that it knows remote tracking branch and thus Unless I missed some obscure documentation part?
I don't see how. It provides full copy of the toolchain with
That is simply different level of operation and I think it is better left to Digger. Adding any state to user system goes beyond the concept of "quick to try, quick to get rid of" startup repository. I see those as different approaches for different use cases.
At the very least - have digger as one of submodules / move it to D-Programming-Language/tools and provide wrapper commands to top-level scripts that call it using the same sandbox layout. I was actually hoping you could spot more opportunities for Digger from such standardized layout :) |
I see. I haven't used it myself.
So rdmd-dev and dub-dev are patched to run dmd-dev instead of dmd?
Well, for one, I think it wouldn't be hard to implement this script's functionality on top of Digger, which shouldn't be very difficult, and which would give it Digger's advantages (caching, getting all dependencies for Win32/Win64, etc.) |
|
With apologies to @Laeeth, I think we should double down on Digger instead of diverting into creating and maintaining a new tool. I knew about Digger but never used it so I neglected its relevance to this. Apologies. I filed https://issues.dlang.org/show_bug.cgi?id=14091. @Laeeth @CyberShadow if there is agreement on the course of action please close this. Thanks. |
|
It certainly makes sense to build on what we have, and it is normal to have experiments that one decides against using. So I shall close this pull request. |
Incidentally, I've started creating binary packages of Digger for all major platforms: |
I have also Arch Linux package for Digger in progress but need to decide on standard layout for file artifact placement first. |
|
@ibuclaw was dealing with the same question while creating Debian/Ubuntu packages just a few days ago. I believe he patched the code to move the "www" directory somewhere else. Let me know if I can help. |
Hi.
Ported update.sh to D - hope this might be of some use. I don't pretend it is pretty generally, and in particular I tried to stick to the structure of the original script for clarity, even though it would be more elegant to factor out the repetition.
Just run makeit.sh to compile - you may want to change the compiler to dmd. I destroyed my system dmd with a null file when working on it, so changed to ldc temporarily.
Laeeth.