On 2013-06-03 19:29, Walter Bright wrote:

> Creating deps and rpms is done from the zip file, and the scripts are here:
>
>     https://github.com/D-Programming-Language/installer

The Mac OS X installer is built from the zip file as well. If we change format or anything similar we need to update the script that builds the installer.

-- 
/Jacob Carlborg

On Tuesday, June 04, 2013 09:16:12 Jacob Carlborg wrote:
> On 2013-06-03 19:29, Walter Bright wrote:
> > Creating deps and rpms is done from the zip file, and the scripts are here:
> >     https://github.com/D-Programming-Language/installer
> 
> The Mac OS X installer is built from the zip file as well. If we change format or anything similar we need to update the script that builds the installer.

If we change the zip, we need to look at _all_ of the various installers/packages which are generated from it, since it looks like _everything_ generated from the zip file at this point.

- Jonathan M Davis

On Tue, 04 Jun 2013 08:57:49 +0200
Jacob Carlborg <doob@me.com> wrote:

> On 2013-06-03 23:08, Nick Sabalausky wrote:
> 
> > I intend to. But I do think it would be good if we then update DVM to use the platform-specific versions, to preserve bandwidth and improve dload/installation speeds.
> 
> I would like to rewrite the whole tool. Then we can fix all these things. Haven't taken the time to do it yet.
> 

Just curious: What sort of direction did you have in mind for a rewrite? Something about the general architecture of it you'd do differently?

> > Possibly related to that, I keep meaning to look into updating DVM to install *both* -m32 and -m64 abilities on appropriate platforms (unless you've already beaten me to it?)
> 
> No, I haven't done that. See above.
> 
> BTW, DVM is not really working on Windows XP, or rather the installed compilers. DVM installs the compilers in a path which contains spaces. The compiler and/or the linker isn't happy with that.
> 

I was using an XP box as my main machine until about a year ago. It always worked fine for me as I recall.

The only "path with spaces" problem I had was when using DVM to build DMD using a version of DMC that was installed by DVM. That lead to a "paths with spaces" problem. I wasn't able to figure that out, although I suspected it may have had something to do with either DMD's makefiles or DMC's make.

On 6/3/2013 5:34 PM, Jonathan M Davis wrote:
> But why create it as a zip file in the first place?

Because creating tarballs on Windows is a big problem, not the least of which you can't create symlinks on Windows, so even if you found a working Windows tar program you still haven't solved the problem.

> Just create the tarball
> correctly when it's built and don't create a zip file at all. Clearly, people
> other than you are going to be sorting this out, but we shouldn't even be
> creating a zip file for the non-Windows OSes in the first place.
> The symlinks should be created as part of the build and tar-ed from there.

It isn't any harder creating a symlink after unzipping than it is creating one before creating a tarball.

On Tuesday, June 04, 2013 00:52:27 Walter Bright wrote:
> On 6/3/2013 5:34 PM, Jonathan M Davis wrote:
> > But why create it as a zip file in the first place?
> 
> Because creating tarballs on Windows is a big problem, not the least of which you can't create symlinks on Windows, so even if you found a working Windows tar program you still haven't solved the problem.

Except that they shouldn't even be being created on Windows in the first place. I understand that this is how you've been doing it, but it would make a lot more sense for a build machine like the auto tester to be generating the tarballs as part of the build. Then they're being built locally to the OSes that they're going to be used on, and the process is properly automatable. We can even have nightly dev releases that way. I believe that this is what Brad Roberts started working on with some recent pull requests towards creating make install targets. Ideally, none of the official build and packaging process would rely on your local setup.

- Jonathan M Davis

On 2013-06-04 09:52, Walter Bright wrote:
> On 6/3/2013 5:34 PM, Jonathan M Davis wrote:
>> But why create it as a zip file in the first place?
>
> Because creating tarballs on Windows is a big problem, not the least of
> which you can't create symlinks on Windows, so even if you found a
> working Windows tar program you still haven't solved the problem.

You can create symlinks on Windows, on versions later than XP. Although I don't know if they're compatible with Posix.

-- 
/Jacob Carlborg

On 2013-06-04 09:39, Nick Sabalausky wrote:

> Just curious: What sort of direction did you have in mind for a rewrite?
> Something about the general architecture of it you'd do differently?

* All the functionality shouldn't be in the commands. The commands should invoke library functions/classes. I won't DVM to be usable as a library. The tool should just be a thin wrapper/user interface around the library.

* I want to support other compilers, at least LDC (GDC doesn't seem so easy).

* The Application module and command line arguments handling is not very DRY. I have factored that out in separate modules in other tools I'm building (DStep, Orbit), I plan to reuse that.

I guess those are the major things I want to do. Then of course fixing all these little things we have been talking about for a while.

-- 
/Jacob Carlborg

On 06/02/2013 03:47 PM, Gary Willoughby wrote:
> I've just run:
>
> sudo ln -s /usr/lib/x86_64-linux-gnu/libphobos2.so
> /usr/lib/x86_64-linux-gnu/libphobos2.so.0.63
>
> for now but i've never had to do that before. Is this a problem with the
> installer?

Sorry that was my fault, I missed that when fixing up the installers.
https://github.com/D-Programming-Language/installer/pull/19

On Monday, 3 June 2013 at 21:18:54 UTC, Nick Sabalausky wrote:
> Also does ".tar.gz" vs ".tar.bz2" matter? I understand that the latter
> (if I spelled it right) is newer and better compression, but any reason
> that it might *need* to be one or the other?
I'd look at xz, it's increasingly becoming the standard packaging format for open source distros:

http://en.wikipedia.org/wiki/Xz#Uses

It usually compresses the tightest and decompresses the fastest, while beating bzip2 on compression time.

On Wednesday, June 05, 2013 19:13:46 Joakim wrote:
> On Monday, 3 June 2013 at 21:18:54 UTC, Nick Sabalausky wrote:
> > Also does ".tar.gz" vs ".tar.bz2" matter? I understand that the
> > latter
> > (if I spelled it right) is newer and better compression, but
> > any reason
> > that it might *need* to be one or the other?
> 
> I'd look at xz, it's increasingly becoming the standard packaging format for open source distros:
> 
> http://en.wikipedia.org/wiki/Xz#Uses
> 
> It usually compresses the tightest and decompresses the fastest, while beating bzip2 on compression time.

In my experience, xz has way worse compression time than bzip2, and on smaller files, it actually compresses worse. Where xz shines are large files. It definitely beats out bzip2 by a fair bit there. But as it loses at small files (which distro packages usually are), it seems very off to me that Arch Linux switched to used xz from gzip. It would have made for more sense to switch to bzip2.

I we split the dmd zip, I question that it would be large enough for xz to compress better than bzip2. And I don't think that xz is supported as well in general as gzip or bzip2. So, I doubt that switching to xz is a good idea.

- Jonathan M Davis