RejectedSoftware Forums

Sign up

Pages: 1 2 3

Re: Released DUB 0.9.21 Beta 3

On Thu, 16 Jan 2014 13:36:26 +0100, Sönke Ludwig wrote:

Am 16.01.2014 13:11, schrieb Sönke Ludwig:

Am 16.01.2014 10:59, schrieb Moritz Maxeiner:

My project
won't compile anymore either (it did with 0.9.21 Beta 1, I believe),
although it's seems to be a different error. Probably there's
something wrong with my package.json, but I can't figure out what.

These are the errors:

Checking dependencies in '/home/cal/Seafile/llvm/llvm-d'
Failed to retrieve metadata for package llvm-d:c-api: Could not find
package candidate for llvm-d:c-api ==~experimental
...

Fixed by
cd6ab73.
However, DMD now fails with:
...

Not sure if this is caused by DUB changes.

No, it's just a bug in the library: llvm/d/constants.d:1060 should be
getShuffleVector instead of getExtractElement.

Thank you for the fix, it works now perfectly (I have local changes for these bugs causing dmd to fail, they're just not yet committed+pushed yet).
This also fixed the other issue I reported here, so I've closed it.

Re: Released DUB 0.9.21 Beta 3

On 2014-01-15 15:09, Sönke Ludwig wrote:

There is a third, and hopefully last, beta version for DUB 0.9.21. It contains four major new features:

What are these version identifiers that Dub passes to the compiler, like
Havename>. I'm wondering how good idea it is that Dub is
passing version flags the user might not know about.

/Jacob Carlborg

Re: Released DUB 0.9.21 Beta 3

Wasn't working until I switched from derelict's subpackages to derelict-gl3, derelict-glfw3, and derelict-fi. Everything works fine now.

Re: Released DUB 0.9.21 Beta 3

On Wed, 15 Jan 2014 14:09:58 GMT, Sönke Ludwig wrote:

There is a third, and hopefully last, beta version for DUB 0.9.21. It contains four major new features:

  • New per-package build system (builds individual packages as static libraries), use --combined to build everything at once (almost) like before

  • New "dub test" command to run the (unit) tests of a project

  • Supports (and recommends) public sub packages in sub folders. For example, the following entry in vibe.d's package description file would make the http server example available as a dependency "vibe-d:http-server-example":

    {
      ...
      "subPackages": {
        "examples/http_server"
      }
    }
    
    
  • The preferred package description file name is now "dub.json" instead of "package.json" (the old name will continue to be supported).

Everything basically works, but a lot of testing is still needed to get a solid release. Please download from http://code.dlang.org/download (or GIT clone from https://github.com/rejectedsoftware/dub.git) and test with your projects, so that any regressions can be worked out early.

Not sure if this is a bug or a problem with a non-properly configured package.json, but the gfm package from code.dlang.org fails to compile: if you create a simple test project:
{

"name": "test",
"description": "A minimal D application.",
"copyright": "Copyright",
"authors": ["me"],
"dependencies": {
    "gfm" : "~master"
}

}
This fails to compile: after building the single subpackages, it appears that a non-valid dmd command is issued:
dub build --verbose
[snip]
Building gfm configuration "library", build type debug.
Ignoring all import libraries for static library build.
Trying to use pkg-config to resolve library flags for [].
pkg-config failed: pkg-config exited with error code 1
Falling back to direct -lxyz flags.
Running dmd...
dmd -lib -of../../.dub/packages/gfm-master/.dub/build/library-debug-x8664-dmd-0F143CEA0D94A974CB517ABFF7D4DCBC/libgfm.a -debug -g -w -version=Havegfm -version=Havegfmmath -version=Havegfmnet -version=Havegfmcore -version=Havegfmassimp -version=Havederelictassimp3 -version=Havederelictutil -version=Havegfmfreeimage -version=Havederelictfi -version=Havegfmimage -version=Havegfmopengl -version=Havederelictgl3 -version=Havegfmsdl2 -version=Havederelictsdl2 -version=Have_temptest -I../../.dub/packages/gfm-master/math -I../../.dub/packages/gfm-master/net -I../../.dub/packages/gfm-master/core -I../../.dub/packages/gfm-master/assimp -I../../.dub/packages/derelict-assimp3-master/source -I../../.dub/packages/derelict-util-1.0.0/source -I../../.dub/packages/gfm-master/freeimage -I../../.dub/packages/derelict-fi-master/source -I../../.dub/packages/gfm-master/image -I../../.dub/packages/gfm-master/opengl -I../../.dub/packages/derelict-gl3-master/source -I../../.dub/packages/gfm-master/sdl2 -I../../.dub/packages/derelict-sdl2-master/source
DMD64 D Compiler v2.064
Copyright (c) 1999-2013 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
Usage:
<blablabla>

Again, my guess it's a package.json problem, but I couldn't find what's wrong, so I'm submitting this. Check it out if you have any spare time!

Re: Released DUB 0.9.21 Beta 3

On Mon, 20 Jan 2014 09:17:02 GMT, Francesco Cattoglio wrote:

(...)
Not sure if this is a bug or a problem with a non-properly configured package.json, but the gfm package from code.dlang.org fails to compile: if you create a simple test project:
(...)

It seems like the gfm root package should specify "targetType": "none" instead of just removing all source/import paths. But since this has obviously worked before, I'll add a check/workaround for this and output a warning to use "targetType" instead.

Re: Released DUB 0.9.21 Beta 3

On Mon, 20 Jan 2014 09:38:54 GMT, Sönke Ludwig wrote:

It seems like the gfm root package should specify "targetType": "none" instead of just removing all source/import paths. But since this has obviously worked before, I'll add a check/workaround for this and output a warning to use "targetType" instead.

Ok, it's a bad pagkage.json then.
When compiling with dub 0.9.20, you actually get a warning already. I guess you just need to get something a bit more informative as output.

Re: Released DUB 0.9.21 Beta 3

On Mon, 20 Jan 2014 10:32:39 GMT, Francesco Cattoglio wrote:

On Mon, 20 Jan 2014 09:38:54 GMT, Sönke Ludwig wrote:

It seems like the gfm root package should specify "targetType": "none" instead of just removing all source/import paths. But since this has obviously worked before, I'll add a check/workaround for this and output a warning to use "targetType" instead.

Ok, it's a bad pagkage.json then.
When compiling with dub 0.9.20, you actually get a warning already. I guess you just need to get something a bit more informative as output.

New warning message and build fix is in 7c23cbe.

Re: Released DUB 0.9.21 Beta 3

On Mon, 20 Jan 2014 11:21:59 GMT, Sönke Ludwig wrote:

New warning message and build fix is in 7c23cbe.

That was quick! Thank you very much =)

Re: Released DUB 0.9.21 Beta 3

On Mon, 20 Jan 2014 09:38:54 GMT, Sönke Ludwig wrote:

It seems like the gfm root package should specify "targetType": "none" instead of just removing all source/import paths. But since this has obviously worked before, I'll add a check/workaround for this and output a warning to use "targetType" instead.

Sorry for not having done that, there is a problem indeed with targetType. It's just that I didn't know which JSON properties get inherited or not.

Re: Released DUB 0.9.21 Beta 3

Am 20.01.2014 13:41, schrieb ponce:

On Mon, 20 Jan 2014 09:38:54 GMT, Sönke Ludwig wrote:

It seems like the gfm root package should specify "targetType": "none" instead of just removing all source/import paths. But since this has obviously worked before, I'll add a check/workaround for this and output a warning to use "targetType" instead.

Sorry for not having done that, there is a problem indeed with targetType. It's just that I didn't know which JSON properties get inherited or not.

No problem at all, there are a lot of corners that need to be documented
better and after all this used to work until now. Also, I need to think
about this some more, because some valid use cases don't work anymore
with the new and fixed compilation model. But at least there should be
alternatives to achieve the same results (the original derelict package
using sub modules is also affected in a similar way).

Pages: 1 2 3