www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Preflight of DUB 0.9.21 (RC 3)

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
DUB 0.9.21 is currently in the RC stage. Before tagging a release, I'd 
like it to get a little more exposure. Apart from checking if building 
works (dependencies are now built separately by default), there are two 
new features that could also benefit from more testing:

  - "dub test" will now automatically execute the unit tests of a
    package (see "dub test --help" for more information)

  - Sub packages can now be in sub folders (the recommended approach):

    "name": "somepack",
    "subPackages": {
        "subpack1/",
        "plugins/someplug/"
    }

    Those sub packages can be publicly referenced as a dependency for
    example as "somepack:subpack1" (assuming that the the package in
    "subpack1")

The binaries can be found on http://code.dlang.org/download ("Latest 
preview").

Pre-release thread on the DUB forum:
http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/965/
Feb 12 2014
next sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig 
wrote:
 dependencies are now built separately by default

You mean DUB won't recompile dependencies from scratch but will do it incrementally? I'm not really sure how it does it right now either.
Feb 12 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 11:11, schrieb Andrej Mitrovic:
 On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
 dependencies are now built separately by default

You mean DUB won't recompile dependencies from scratch but will do it incrementally? I'm not really sure how it does it right now either.

In 0.9.20, it used to gather all source files of all packages in the dependency tree and built them at once (when necessary). Now, by default, it will build each dependency as a separate static library and also builds only those dependencies that have changed or those that depend on other dependencies that have changed. The --combined switch can be used to get (almost) the old behavior. Almost, because DUB now also respects the exact "targetType" of a package and will always build a static library if "staticLibrary" is given and aways includes the source files on the parent package build command when "sourceLibrary" is used. Previously, all dependencies were basically treated as "sourceLibrary".
Feb 12 2014
prev sibling next sibling parent "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Wednesday, 12 February 2014 at 10:58:28 UTC, Sönke Ludwig 
wrote:
 In 0.9.20, it used to gather all source files of all packages 
 in the dependency tree and built them at once (when necessary). 
 Now, by default, it will build each dependency as a separate 
 static library.

Nice. Hope it works fine (especially w.r.t. that -allinst mess we've had since recently).
Feb 12 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig 
wrote:
 DUB 0.9.21 is currently in the RC stage. Before tagging a 
 release, I'd like it to get a little more exposure. Apart from 
 checking if building works (dependencies are now built 
 separately by default)

How do I handle `example` subdirectories with the new build process? I looked at vibe.d's examples (the simple HTTP server stuff to be specific) but they don't seem to handle linking (do they really build without --combined?). Is there a way to add linker search directories so my examples can link to the library's static library builds? Or is this supposed to be handled automatically for library dependencies?
  - "dub test" will now automatically execute the unit tests of a
    package (see "dub test --help" for more information)

I can confirm this works for the LuaD package, which is a pretty typical D library in terms of structure.
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 14:14, schrieb Jakob Ovrum:
 On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
 DUB 0.9.21 is currently in the RC stage. Before tagging a release, I'd
 like it to get a little more exposure. Apart from checking if building
 works (dependencies are now built separately by default)

How do I handle `example` subdirectories with the new build process? I looked at vibe.d's examples (the simple HTTP server stuff to be specific) but they don't seem to handle linking (do they really build without --combined?). Is there a way to add linker search directories so my examples can link to the library's static library builds? Or is this supposed to be handled automatically for library dependencies?

The latter. The target binaries of dependencies (recursively) are automatically linked against the final application. Specifying linker search paths is not possible right now (at least some time ago this was problematic for DMD on Windows, not sure what the current state is). But specific library files can be added as `"sourceFiles"`. Those will be passed to the compiler at the linking stage, which passes them on to the linker.
  - "dub test" will now automatically execute the unit tests of a
    package (see "dub test --help" for more information)

I can confirm this works for the LuaD package, which is a pretty typical D library in terms of structure.

Thanks for testing!
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 19:56, schrieb Jakob Ovrum:
 On Wednesday, 12 February 2014 at 18:06:19 UTC, Sönke Ludwig wrote:
 The latter. The target binaries of dependencies (recursively) are
 automatically linked against the final application.

Hm, I'm getting a failure to link, with just one symbol reported missing. Further, -allinst makes no difference. I checked the verbose output and the parent library was indeed being passed automatically when linking the example executable, so for now I assume it's a DMD/OPTLINK bug. I'll report back with more information if I can't reproduce it without Dub.

I've reduced it and filed a bug: https://d.puremagic.com/issues/show_bug.cgi?id=12144 It was actually great that this occurred in LuaD, because I suspect that I'm possibly hit by the same bug, but my code base is so large that it takes over a week to run dustmite on it.
Feb 12 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 21:36, schrieb Jakob Ovrum:
 On Wednesday, 12 February 2014 at 20:34:35 UTC, Jakob Ovrum wrote:
 On Wednesday, 12 February 2014 at 20:24:28 UTC, Sönke Ludwig wrote:
 I've reduced it and filed a bug:

 https://d.puremagic.com/issues/show_bug.cgi?id=12144

 It was actually great that this occurred in LuaD, because I suspect
 that I'm possibly hit by the same bug, but my code base is so large
 that it takes over a week to run dustmite on it.

Wow, well done. Sorry for not including all the relevant information right away, might have saved you some time. I was actually putting all the information together for the post, but as I saw using --verbose that everything *looked* right, I decided to wait and see if it really was a problem with Dub first - you were one step ahead of me there. Thanks!

... which the unreferenced reference at the bottom of my post revealed, lol.

Yeah, that helped a lot ;) No, but overall it went pretty quick, with a little Dustmite help and (spoiling the news) the upcoming Dustmite integration into DUB, which was also very helpful when reducing the rest by hand.
Feb 12 2014
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download ("Latest preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit. -- Jordi Sayol
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 16:40, schrieb Jordi Sayol:
 El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download ("Latest preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit.

I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit, hopefully that works...
Feb 12 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 12.02.2014 19:12, schrieb Sönke Ludwig:
 Am 12.02.2014 16:40, schrieb Jordi Sayol:
 El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download ("Latest
 preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit.

I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit, hopefully that works...

Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.
Feb 12 2014
next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 10:28, schrieb Russel Winder:
 On Thu, 2014-02-13 at 00:18 +0100, Sönke Ludwig wrote:
 […]
 Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.

I missed earlier activity, but just downloaded the Linux x86_64 0.9.21-rc3 and it appears to work fine on Debian Sid (Unstable). Except… …I have no idea what to put in the package.json file to get rid of this problem: source/main.d(27): Error: need -Jpath switch to import text file VERSION http://code.dlang.org/package-format doesn't mention this option. -J. is all I need given my SCons build of this same project.

That's the "stringImportPaths" field which corresponds to -J, there should probably be a small note to which DMD flag each field corresponds (if applicable, of course).
Feb 13 2014
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 11:55, schrieb "Casper Færgemand" <shorttail hotmail.com>":
 Nice to see the dependencies not having to be compiled over and over
 again. One thing though: It seems dependencies are compiled with -m32
 and my source with -m64, meaning they have different object formats in
 Windows, and the linker chokes.

Good catch. I'll look into that.
Feb 13 2014
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 11:39, schrieb extrawurst:
 On Wednesday, 12 February 2014 at 23:18:07 UTC, Sönke Ludwig wrote:
 Am 12.02.2014 19:12, schrieb Sönke Ludwig:
 Am 12.02.2014 16:40, schrieb Jordi Sayol:
 El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download ("Latest
 preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit.

I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit, hopefully that works...

Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.

I just tried to run dub on Amazon ami linux. Although it runs it prints: dub: /usr/lib64/libcurl.so.4: no version information available (required by dub) Is that a problem ? WOuld it be fixed if I built dub myself there ?

libcurl is a dependency of Phobos, so I'm actually not sure. Maybe it's necessary to rebuild Phobos, too.
Feb 13 2014
prev sibling next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 12:40, schrieb Russel Winder:
 I just tried the Linux x86_64 executable on Fedora 20, and it works
 except for:

 dub: /lib64/libcurl.so.4: no version information available (required by
 dub)

 I am not entirely sure why it doesn't find:

 /usr/lib64/libcurl.so.4
 /usr/lib/libcurl.so.4

 which are most definitely present.

Looks like this is more common than it seemed. I can try to compile on the older Ubuntu 11.10 VM, or, if someone can donate an RPM recipe and the necessary commands, I could also set up a Fedora VM and provide a proper RPM package.
 I also tried the OSX executable on a Mavericks machine and it works
 fine, except…

 … I have a single filestore and thus a single ~/.dub but the compilation
 products of dub are not in architecture dependent locations so I cannot
 work with OSX and Linux at the same time.

I'll add the OS to the generated folder names, I didn't think of this case when defining the format of those and wanted to keep them as short as possible.
 There perhaps needs to be a way of dub cleaning the ~/.dub hierarchy,
 currently I seem to have to manually search all the dependencies and
 clean up. In fact, is there a clean command to dub to clean the project
 and the ~/.dub?

There is an enhancement request for this, but it hasn't been implemented, yet. What is there, though, is the --force switch for forcing a rebuild.
Feb 13 2014
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 20:15, schrieb Etienne:
 On Thursday, 13 February 2014 at 19:13:30 UTC, Etienne wrote:
 $ rpm-build -ba dmd.spec

Sorry, that was $ rpmbuild -ba dmd.spec rpm-build is the package name, rpmbuild is the binary filename.

Thank you! Would it also be possible to make a binary-only package from a pre-built binary without the dmd dependency? The way it is now, it would be nice to have in a full repository like the one Jordi Sayol maintains for Debian, but it's less practical for direct distribution.
Feb 13 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 14.02.2014 01:25, schrieb Etienne:
 On Thursday, 13 February 2014 at 20:17:39 UTC, Sönke Ludwig wrote:
 The way it is now, it would be nice to have in a full repository like
 the one Jordi Sayol maintains for Debian, but it's less practical for
 direct distribution.

I provided the dmd.spec because I took the opportunity to make one as well, but it's not a dependency here. It may be easier to install the most recent dmd master using it, because the RPMs for DMD are currently generated through these shell scripts: https://github.com/D-Programming-Language/installer/tree/master/linux And I thought you may want to supply it with dub in case people are newcomers and want the most recent version. But the dub x64 RPM that is generated from this dub.spec file will be a binary file that depends only on libcurl, it carries a dub binary with some requirements and installation paths (/usr/bin). In any case, every time you issue a new dub release, you'll still need to generate a x64 DEB, x86 DEB, x64 RPM and x86 RPM file as well to distribute it on every linux platform. You should use debian 6 and fedora 18, always a couple versions behind, to make sure its not built against too recent libraries. Do you want me to provide something more convenient, or can you do with dub.spec files & rpmbuild?

Oh okay, I just misunderstood how the spec file works then. I'll just change it to use the already checked out source and put it into the installer folder [1] then. Is it possible to make the package version dynamic to match the current git tag somehow? For example by using an environment variable or by passing the version to rpmbuild? DEB packages are already kindly maintained by Jordi Sayol, so I can leave those out. [1]: https://github.com/rejectedsoftware/dub/tree/master/installer
Feb 14 2014
prev sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 13:20, schrieb Sönke Ludwig:
 Am 13.02.2014 12:40, schrieb Russel Winder:
 … I have a single filestore and thus a single ~/.dub but the compilation
 products of dub are not in architecture dependent locations so I cannot
 work with OSX and Linux at the same time.

I'll add the OS to the generated folder names, I didn't think of this case when defining the format of those and wanted to keep them as short as possible.

Done in RC 4
Feb 13 2014
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 11:55, schrieb "Casper Færgemand" <shorttail hotmail.com>":
 It seems dependencies are compiled with -m32
 and my source with -m64, meaning they have different object formats in
 Windows, and the linker chokes.

After some testing, all I can get is multiple -m64 switches, which isn't pretty, but shouldn't do any harm. Do you compile with --arch=x86_64 or did you manually add the -m64 flag somewhere? The latter would explain the issue, as only -version= flags are inherited downwards to the dependencies (except for build type flags).
Feb 13 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 13:58, schrieb "Casper Færgemand" <shorttail hotmail.com>":
 On Thursday, 13 February 2014 at 12:57:02 UTC, Sönke Ludwig wrote:
 After some testing, all I can get is multiple -m64 switches, which
 isn't pretty, but shouldn't do any harm. Do you compile with
 --arch=x86_64 or did you manually add the -m64 flag somewhere? The
 latter would explain the issue, as only -version= flags are inherited
 downwards to the dependencies (except for build type flags).

Herp derp, didn't know about that one. It works now. Is it possible to specify in package.json?

Currently it can be controlled only by command line switches. But how about the possibility of configuring a default architecture in the user or system wide dub configuration file? And possibly also per package in a configuration file in "package-path/.dub/"... but it seems to me that this should stay independent of the package description, since the platform is more or less determined by the target machine and not the package itself, or do you have a specific use case in mind?
Feb 13 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 18:06:19 UTC, Sönke Ludwig 
wrote:
 The latter. The target binaries of dependencies (recursively) 
 are automatically linked against the final application.

Hm, I'm getting a failure to link, with just one symbol reported missing. Further, -allinst makes no difference. I checked the verbose output and the parent library was indeed being passed automatically when linking the example executable, so for now I assume it's a DMD/OPTLINK bug. I'll report back with more information if I can't reproduce it without Dub. Really cool that libraries are automatically linked, I'm really liking how Dub is shaping up!
 Specifying linker search paths is not possible right now (at 
 least some time ago this was problematic for DMD on Windows, 
 not sure what the current state is). But specific library files 
 can be added as `"sourceFiles"`. Those will be passed to the 
 compiler at the linking stage, which passes them on to the 
 linker.

Yeah, I remember OPTLINK being difficult in this regard. IIRC though, there is an environment variable one can set. [1] https://github.com/JakobOvrum/LuaD/tree/master/example/hello
Feb 12 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 20:24:28 UTC, Sönke Ludwig 
wrote:
 I've reduced it and filed a bug:

 https://d.puremagic.com/issues/show_bug.cgi?id=12144

 It was actually great that this occurred in LuaD, because I 
 suspect that I'm possibly hit by the same bug, but my code base 
 is so large that it takes over a week to run dustmite on it.

Wow, well done. Sorry for not including all the relevant information right away, might have saved you some time. I was actually putting all the information together for the post, but as I saw using --verbose that everything *looked* right, I decided to wait and see if it really was a problem with Dub first - you were one step ahead of me there. Thanks!
Feb 12 2014
prev sibling next sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 20:34:35 UTC, Jakob Ovrum wrote:
 On Wednesday, 12 February 2014 at 20:24:28 UTC, Sönke Ludwig 
 wrote:
 I've reduced it and filed a bug:

 https://d.puremagic.com/issues/show_bug.cgi?id=12144

 It was actually great that this occurred in LuaD, because I 
 suspect that I'm possibly hit by the same bug, but my code 
 base is so large that it takes over a week to run dustmite on 
 it.

Wow, well done. Sorry for not including all the relevant information right away, might have saved you some time. I was actually putting all the information together for the post, but as I saw using --verbose that everything *looked* right, I decided to wait and see if it really was a problem with Dub first - you were one step ahead of me there. Thanks!

... which the unreferenced reference at the bottom of my post revealed, lol.
Feb 12 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig 
wrote:
 DUB 0.9.21 is currently in the RC stage. Before tagging a 
 release, I'd like it to get a little more exposure. Apart from 
 checking if building works (dependencies are now built 
 separately by default), there are two new features that could 
 also benefit from more testing:

  - "dub test" will now automatically execute the unit tests of a
    package (see "dub test --help" for more information)

  - Sub packages can now be in sub folders (the recommended 
 approach):

    "name": "somepack",
    "subPackages": {
        "subpack1/",
        "plugins/someplug/"
    }

    Those sub packages can be publicly referenced as a 
 dependency for
    example as "somepack:subpack1" (assuming that the the 
 package in
    "subpack1")

 The binaries can be found on http://code.dlang.org/download 
 ("Latest preview").

 Pre-release thread on the DUB forum:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/965/

Added package description files for all the LuaD examples, and they all work using the new build model with the exception of the `hello` example (which you are aware of). The dynamic library example also builds correctly, but it would be nice to have a way to specify how to run it, so I filed that over at the dub issue tracker. I also reworked LuaD's readme files to emphasize dub :)
Feb 12 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 13.02.2014 02:01, schrieb Jakob Ovrum:
 On Wednesday, 12 February 2014 at 08:53:56 UTC, Sönke Ludwig wrote:
 DUB 0.9.21 is currently in the RC stage. Before tagging a release, I'd
 like it to get a little more exposure. Apart from checking if building
 works (dependencies are now built separately by default), there are
 two new features that could also benefit from more testing:

  - "dub test" will now automatically execute the unit tests of a
    package (see "dub test --help" for more information)

  - Sub packages can now be in sub folders (the recommended approach):

    "name": "somepack",
    "subPackages": {
        "subpack1/",
        "plugins/someplug/"
    }

    Those sub packages can be publicly referenced as a dependency for
    example as "somepack:subpack1" (assuming that the the package in
    "subpack1")

 The binaries can be found on http://code.dlang.org/download ("Latest
 preview").

 Pre-release thread on the DUB forum:
 http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/965/

Added package description files for all the LuaD examples, and they all work using the new build model with the exception of the `hello` example (which you are aware of). The dynamic library example also builds correctly, but it would be nice to have a way to specify how to run it, so I filed that over at the dub issue tracker. I also reworked LuaD's readme files to emphasize dub :)

Nice! The dylib run addition will be scheduled for the next release (hopefully ready in about 3 weeks).
Feb 13 2014
prev sibling next sibling parent "Etienne Cimon" <etcimon gmail.com> writes:
On Wednesday, 12 February 2014 at 15:40:27 UTC, Jordi Sayol wrote:
 El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download 
 ("Latest preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit.

You'll find the version of >= GLIBC_2.14 in debian's experimental repo in aptitude. $ sudo vim /etc/apt/sources.list in this file you can append: deb http://ftp.debian.org/debian/ experimental main deb-src http://ftp.debian.org/debian/ experimental main Then you can run $ sudo apt-get -t experimental update && sudo apt-get -t experimental upgrade You should receive glibc 2.18-* experimental which is >=2.14 i.e. compatible with dub 0.9.21 You should also install the most recent version of libevent with $ sudo apt-cache search libevent-2* which should return libevent-2.0-5, in which case you can run $ sudo apt-get libevent-2.0-5 libevent-pthreads-2.0-5 libevent-dev That should do :)
Feb 12 2014
prev sibling next sibling parent "Etienne Cimon" <etcimon gmail.com> writes:
It's worth nothing that dub.json runs as a project file in mono-d 
monodevelop IDE as well. Every dependency loads in the project 
tree. So, all in all, with git, autocomplete and everything, it's 
becoming very stable, cross-platform and beautifully integrated. 
It all makes D feel like a convenient programming language to 
use, when even 3 months ago the same dub&mono-d setup was totally 
impossible to use even though it was there. The developers on 
this are so good it seems like there's 1000s of men putting it 
all together.
Feb 12 2014
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
El 13/02/14 00:18, Sönke Ludwig ha escrit:
 Am 12.02.2014 19:12, schrieb Sönke Ludwig:
 Am 12.02.2014 16:40, schrieb Jordi Sayol:
 El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download ("Latest
 preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit.

I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit, hopefully that works...

Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.

It properly runs even on Debian 6 x64. Thanks! -- Jordi Sayol
Feb 12 2014
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
El 13/02/14 05:28, Etienne Cimon ha escrit:
 On Wednesday, 12 February 2014 at 15:40:27 UTC, Jordi Sayol wrote:
 El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download ("Latest preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit.

You'll find the version of >= GLIBC_2.14 in debian's experimental repo in aptitude. $ sudo vim /etc/apt/sources.list in this file you can append: deb http://ftp.debian.org/debian/ experimental main deb-src http://ftp.debian.org/debian/ experimental main Then you can run $ sudo apt-get -t experimental update && sudo apt-get -t experimental upgrade You should receive glibc 2.18-* experimental which is >=2.14 i.e. compatible with dub 0.9.21 You should also install the most recent version of libevent with $ sudo apt-cache search libevent-2* which should return libevent-2.0-5, in which case you can run $ sudo apt-get libevent-2.0-5 libevent-pthreads-2.0-5 libevent-dev That should do :)

Thank you but this should be done by every Debian 6 or 7 dub user. The easiest way to fix this is to compile dub on Debian 6 or 7. Regards, -- Jordi Sayol
Feb 13 2014
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-02-13 at 00:18 +0100, Sönke Ludwig wrote:
[…]
 Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.

I missed earlier activity, but just downloaded the Linux x86_64 0.9.21-rc3 and it appears to work fine on Debian Sid (Unstable). Except… …I have no idea what to put in the package.json file to get rid of this problem: source/main.d(27): Error: need -Jpath switch to import text file VERSION http://code.dlang.org/package-format doesn't mention this option. -J. is all I need given my SCons build of this same project. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 13 2014
prev sibling next sibling parent "extrawurst" <stephan extrawurst.org> writes:
On Wednesday, 12 February 2014 at 23:18:07 UTC, Sönke Ludwig 
wrote:
 Am 12.02.2014 19:12, schrieb Sönke Ludwig:
 Am 12.02.2014 16:40, schrieb Jordi Sayol:
 El 12/02/14 09:53, Sönke Ludwig ha escrit:
 The binaries can be found on http://code.dlang.org/download 
 ("Latest
 preview").

On Debian 7.4 64-bit: $ dub dub: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by dub) No problem on Debian 7.4 32-bit.

I'll build the next RC with Debian 6 instead of Ubuntu 12.04 for 64-bit, hopefully that works...

Okay, uploaded a new version of RC 3 built on Debian 7 x64 instead.

I just tried to run dub on Amazon ami linux. Although it runs it prints: dub: /usr/lib64/libcurl.so.4: no version information available (required by dub) Is that a problem ? WOuld it be fixed if I built dub myself there ?
Feb 13 2014
prev sibling next sibling parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
Nice to see the dependencies not having to be compiled over and 
over again. One thing though: It seems dependencies are compiled 
with -m32 and my source with -m64, meaning they have different 
object formats in Windows, and the linker chokes.
Feb 13 2014
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
I just tried the Linux x86_64 executable on Fedora 20, and it works
except for:

dub: /lib64/libcurl.so.4: no version information available (required by
dub)

I am not entirely sure why it doesn't find:

/usr/lib64/libcurl.so.4
/usr/lib/libcurl.so.4

which are most definitely present.

I also tried the OSX executable on a Mavericks machine and it works
fine, except…

… I have a single filestore and thus a single ~/.dub but the compilation
products of dub are not in architecture dependent locations so I cannot
work with OSX and Linux at the same time.

There perhaps needs to be a way of dub cleaning the ~/.dub hierarchy,
currently I seem to have to manually search all the dependencies and
clean up. In fact, is there a clean command to dub to clean the project
and the ~/.dub? 

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Feb 13 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 13 February 2014 at 11:40:56 UTC, Russel Winder 
wrote:
 I just tried the Linux x86_64 executable on Fedora 20, and it 
 works
 except for:

 dub: /lib64/libcurl.so.4: no version information available 
 (required by
 dub)

 I am not entirely sure why it doesn't find:

 /usr/lib64/libcurl.so.4
 /usr/lib/libcurl.so.4

 which are most definitely present.

 I also tried the OSX executable on a Mavericks machine and it 
 works
 fine, except…

 … I have a single filestore and thus a single ~/.dub but the 
 compilation
 products of dub are not in architecture dependent locations so 
 I cannot
 work with OSX and Linux at the same time.

 There perhaps needs to be a way of dub cleaning the ~/.dub 
 hierarchy,
 currently I seem to have to manually search all the 
 dependencies and
 clean up. In fact, is there a clean command to dub to clean the 
 project
 and the ~/.dub?

https://github.com/rejectedsoftware/dub/issues/134 In the mean time I would just delete the whole ~/.dub folder every time you change OS.
Feb 13 2014
prev sibling next sibling parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail hotmail.com> writes:
On Thursday, 13 February 2014 at 12:57:02 UTC, Sönke Ludwig wrote:
 After some testing, all I can get is multiple -m64 switches, 
 which isn't pretty, but shouldn't do any harm. Do you compile 
 with --arch=x86_64 or did you manually add the -m64 flag 
 somewhere? The latter would explain the issue, as only 
 -version= flags are inherited downwards to the dependencies 
 (except for build type flags).

Herp derp, didn't know about that one. It works now. Is it possible to specify in package.json?
Feb 13 2014
prev sibling next sibling parent "Etienne" <etcimon gmail.com> writes:
On Thursday, 13 February 2014 at 12:20:09 UTC, Sönke Ludwig wrote:
 Looks like this is more common than it seemed. I can try to 
 compile on the older Ubuntu 11.10 VM, or, if someone can donate 
 an RPM recipe and the necessary commands, I could also set up a 
 Fedora VM and provide a proper RPM package.

Ask and ye shall receive https://github.com/GlobecSys/w3Vibe/blob/master/dmd.spec https://github.com/GlobecSys/w3Vibe/blob/master/dub.spec You should run this before: $ yum install rpm-build binutils libstdc++-devel wget gcc gcc-c++ make openssl libcurl-devel tar kernel-devel then you can run $ rpm-build -ba dmd.spec $ rpm -ivh ~/rpmbuild/RPMS/x86_64/dmd*.rpm $ rpm-build -ba dub.spec Your RPMs will be in ~/rpmbuilds/RPMS/x86_64 I didn't get into making a i686 version of the spec.. I assume it's just a matter of changing %define _archmodel 64 to %define _archmodel 32 in dmd.spec, but for dub I'm not too sure how it handles it.
Feb 13 2014
prev sibling next sibling parent "Etienne" <etcimon gmail.com> writes:
On Thursday, 13 February 2014 at 19:13:30 UTC, Etienne wrote:
 $ rpm-build -ba dmd.spec

Sorry, that was $ rpmbuild -ba dmd.spec rpm-build is the package name, rpmbuild is the binary filename.
Feb 13 2014
prev sibling next sibling parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
Uploaded RC 4 with fixes for the issues encountered so far. If no other 
critical error or regression occurs, this one will go final.
Feb 13 2014
prev sibling next sibling parent "Etienne" <etcimon gmail.com> writes:
On Thursday, 13 February 2014 at 20:17:39 UTC, Sönke Ludwig wrote:
 The way it is now, it would be nice to have in a full 
 repository like the one Jordi Sayol maintains for Debian, but 
 it's less practical for direct distribution.

I provided the dmd.spec because I took the opportunity to make one as well, but it's not a dependency here. It may be easier to install the most recent dmd master using it, because the RPMs for DMD are currently generated through these shell scripts: https://github.com/D-Programming-Language/installer/tree/master/linux And I thought you may want to supply it with dub in case people are newcomers and want the most recent version. But the dub x64 RPM that is generated from this dub.spec file will be a binary file that depends only on libcurl, it carries a dub binary with some requirements and installation paths (/usr/bin). In any case, every time you issue a new dub release, you'll still need to generate a x64 DEB, x86 DEB, x64 RPM and x86 RPM file as well to distribute it on every linux platform. You should use debian 6 and fedora 18, always a couple versions behind, to make sure its not built against too recent libraries. Do you want me to provide something more convenient, or can you do with dub.spec files & rpmbuild?
Feb 13 2014
prev sibling next sibling parent "Etienne" <etcimon gmail.com> writes:
On Friday, 14 February 2014 at 00:25:43 UTC, Etienne wrote:
 On Thursday, 13 February 2014 at 20:17:39 UTC, Sönke Ludwig 
 wrote:
 Do you want me to provide something more convenient, or can you 
 do with dub.spec files & rpmbuild?

Well of course it would be best for any multi-platform program to have grouped generators in this way: https://github.com/D-Programming-Language/installer/ The spec file only covers RPMs from fedora/centos/rhel, but there's tons of other platforms.
Feb 13 2014
prev sibling next sibling parent "Etienne" <etcimon gmail.com> writes:
 On Friday, 14 February 2014 at 00:25:43 UTC, Etienne wrote:
 The spec file only covers RPMs from fedora/centos/rhel, but 
 there's tons of other platforms.

I put some thought into it some more and you were probably talking about a linux generic 32bit binary that never needs to be updated, and sends platform info to a vibe.d server, which sends back most recent RPM/DEB/etc or if it's not built yet and the server can also automatically build the RPM from the github master if it's not the most recent and send it to be installed.
Feb 13 2014
prev sibling next sibling parent "Casper =?UTF-8?B?RsOmcmdlbWFuZCI=?= <shorttail gmail.com> writes:
On Thursday, 13 February 2014 at 20:39:34 UTC, Sönke Ludwig wrote:
 Currently it can be controlled only by command line switches. 
 But how about the possibility of configuring a default 
 architecture in the user or system wide dub configuration file?

 And possibly also per package in a configuration file in 
 "package-path/.dub/"... but it seems to me that this should 
 stay independent of the package description, since the platform 
 is more or less determined by the target machine and not the 
 package itself, or do you have a specific use case in mind?

I'm not sure what would be a good solution, honestly. My trouble comes from Vibe.d not supporting 64 bit Windows (at least previously) and SIMD not supporting 32 bit Windows, meaning I can't set a global switch in the compiler configuration file either, but I guess the general use of the switch would be to fit the actual architecture and not some silly issue like mine. I suppose the manual switch will do.
Feb 15 2014
prev sibling parent reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
Hopefully the final release candidate has been uploaded. The new RPM 
package could need some testing:

http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
http://code.dlang.org/download
Feb 20 2014
next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
El 20/02/14 17:04, Sönke Ludwig ha escrit:
 Hopefully the final release candidate has been uploaded. The new RPM package
could need some testing:
 
 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download
 

dub rc5 binaries properly tested on Debian 6. New rpm package properly tested on Fedora 14, Fedora 18 and OpenSUSE 12.4 Will be a rpm 32-bit version? -- Jordi Sayol
Feb 20 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 20.02.2014 21:38, schrieb Jordi Sayol:
 El 20/02/14 17:04, Sönke Ludwig ha escrit:
 Hopefully the final release candidate has been uploaded. The new RPM package
could need some testing:

 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download

dub rc5 binaries properly tested on Debian 6. New rpm package properly tested on Fedora 14, Fedora 18 and OpenSUSE 12.4

Thanks a lot for testing! I'll tag this as a release if nothing else happens until then.
 Will be a rpm 32-bit version?

Yes, should be no problem, but I'd like to load that off to the next version together with an outstanding automation issue (the RPM still needs to be uploaded manually in contrast to all the other files) and an improved download page layout.
Feb 21 2014
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote:
 Hopefully the final release candidate has been uploaded. The new RPM 
 package could need some testing:
 
 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download

The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't had chance to test other things yet. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 21 2014
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2014-02-21 at 17:40 +0000, Russel Winder wrote:
 On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote:
 Hopefully the final release candidate has been uploaded. The new RPM 
 package could need some testing:
 
 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download

The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't had chance to test other things yet.

It also works on Fedora 20, but with the: dub: /lib64/libcurl.so.4: no version information available (required by dub) line. I installed the RPM on Fedora 20 and it it works fine without the above message. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 22 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
Am 22.02.2014 11:43, schrieb Russel Winder:
 On Fri, 2014-02-21 at 17:40 +0000, Russel Winder wrote:
 On Thu, 2014-02-20 at 17:04 +0100, Sönke Ludwig wrote:
 Hopefully the final release candidate has been uploaded. The new RPM
 package could need some testing:

 http://code.dlang.org/files/dub-0.9.21-0.rc.5.x86_64.rpm
 http://code.dlang.org/download

The 64-bit Tarball for Linux works for me on Debian Unstable. Haven't had chance to test other things yet.

It also works on Fedora 20, but with the: dub: /lib64/libcurl.so.4: no version information available (required by dub) line. I installed the RPM on Fedora 20 and it it works fine without the above message.

Thanks for the confirmation, I've just uploaded the final packages.
Feb 22 2014
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Sat, 2014-02-22 at 12:22 +0100, Sönke Ludwig wrote:
[…]
 Thanks for the confirmation, I've just uploaded the final packages.

Picked up the new, final release: the RPM works exactly as it should upgrading the rc5 one. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 22 2014