www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DUB 0.9.22 released

reply =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
After again a longer-than-anticipated wait, the next release of the DUB 
package and build manager is finally ready. This is a major milestone 
with some important changes in the way dependency versions are handled, 
making it more robust for a rapidly growing ecosystem. The number of 
available packages is now well above the 300 mark and keeps growing 
steadily:

http://vibed.org/temp/dub-packages.png


But even more important, I'm pleased to announce that DUB is now 
officially developed as part of the D language ecosystem! Based on the 
decision back during this year's DConf, the repository has been migrated 
to the D-Programming-Language organization on GitHub [1], and we are now 
working towards a 1.0.0 milestone [2] that is supposed to be ready for 
inclusion into the official DMD installation package.

If you can think of any potentially important and especially 
backwards-incompatible changes/additions, please mention them (ideally 
as GitHub tickets), so that we can include them before the 1.0.0 release.


Major changes and additions in 0.9.22 include:

  - Improved dependency version handling scheme. Version upgrades are
    now explicit, with the current snapshot being stored in the
    "dub.selections.json" file. This is similar to how other popular
    systems, such as Bundler [3], work, but built into the core system.
    Committing "dub.selections.json" to the repository ensures that
    everyone gets the same (working) combination of dependency versions.

  - Branch based dependencies (e.g. "~master") have been deprecated due
    to their destructive influence on the package ecosystem. See the
    wiki [4] for more information, including on the alternative
    approaches that are now supported.

  - Simple DustMite [5] integration. Using the "dub dustmite" command it
    is now possible to reduce bugs in DUB packages with ease, even in
    complex package hierarchies. The condition used for reduction can be
    specified in terms of exit code or as a regular expression on the
    output of either the compiler, linker, or final executable.

  - Added BASH and FISH shell completion scripts.

  - Added general support for single-file compilation mode, as well as
    separate compile/link mode for GDC.

  - Platform detection now also works when cross-compiling.

  - Added the "*" version specifier to match any version, and path based
    dependencies don't need to specify an explicit version anymore.


As always, find the full list of changes in the change log [6] and 
download at:

http://code.dlang.org/download


[1]: https://github.com/D-Programming-Language/dub/
[2]: 
https://github.com/D-Programming-Language/dub/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0
[3]: http://bundler.io/
[4]: https://github.com/D-Programming-Language/dub/wiki/Version-management
[5]: https://github.com/CyberShadow/DustMite/wiki
[6]: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md
Sep 22 2014
next sibling parent reply Mathias Lang via Digitalmars-d-announce writes:
Awesome :)
Thanks for the time you put in dub, it has become a vital part in D now.

2014-09-22 11:33 GMT+02:00 S=C3=B6nke Ludwig <
digitalmars-d-announce puremagic.com>:


 If you can think of any potentially important and especially
 backwards-incompatible changes/additions, please mention them (ideally as
 GitHub tickets), so that we can include them before the 1.0.0 release.


Full shared library support (building them, and as dependency).

Aside from that, any plan to move the auto-tester to puremagic ? Currently,
Travis works under linux (IIRC OSX is not activated), so dub is not
auto-tested on windows. Also, the test cases are very basic.
Sep 22 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 22.09.2014 12:24, schrieb Mathias Lang via Digitalmars-d-announce:

 Awesome :)
 Thanks for the time you put in dub, it has become a vital part in D now.

 2014-09-22 11:33 GMT+02:00 Sönke Ludwig
 <digitalmars-d-announce puremagic.com
 <mailto:digitalmars-d-announce puremagic.com>>:


     If you can think of any potentially important and especially
     backwards-incompatible changes/additions, please mention them
     (ideally as GitHub tickets), so that we can include them before the
     1.0.0 release.


 Full shared library support (building them, and as dependency).


Sounds like a good candidate. Fortunately this would be a fully 
backwards compatible change, so that it wouldn't be a blocker per-se.


 Aside from that, any plan to move the auto-tester to puremagic ?
 Currently, Travis works under linux (IIRC OSX is not activated), so dub
 is not auto-tested on windows. Also, the test cases are very basic.


That would be a good thing - with more tests (and that is definitely 
something that needs to be worked on, especially high level tests) it 
will be more important to have a Windows tester, too, but so far 
Travis/Linux has generally been sufficient, so there is no need for hurry.
Sep 22 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 22/09/14 13:26, Sönke Ludwig wrote:


 That would be a good thing - with more tests (and that is definitely
 something that needs to be worked on, especially high level tests) it
 will be more important to have a Windows tester, too, but so far
 Travis/Linux has generally been sufficient, so there is no need for hurry.


At least enable OS X if it's not enabled already.

-- 
/Jacob Carlborg
Sep 22 2014
prev sibling parent reply "Poyeyo" <poyeyo arcadechaser.com> writes:
On Monday, 22 September 2014 at 11:26:58 UTC, Sönke Ludwig wrote:

 That would be a good thing - with more tests (and that is 
 definitely something that needs to be worked on, especially 
 high level tests) it will be more important to have a Windows 
 tester, too, but so far Travis/Linux has generally been 
 sufficient, so there is no need for hurry.


Do you need a Windows tester or is that something automated?
Sep 22 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 22.09.2014 17:59, schrieb Poyeyo:

 On Monday, 22 September 2014 at 11:26:58 UTC, Sönke Ludwig wrote:

 That would be a good thing - with more tests (and that is definitely
 something that needs to be worked on, especially high level tests) it
 will be more important to have a Windows tester, too, but so far
 Travis/Linux has generally been sufficient, so there is no need for
 hurry.


 Do you need a Windows tester or is that something automated?


No exactly, an automated tester. The majority of the time I'm working on 
Windows, so it's usually reasonably well tested there in general.
Sep 22 2014
prev sibling next sibling parent reply "Suliman" <evermind live.ru> writes:
I thought that new version of DUB will bring SDL instead json ...
Sep 22 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 22.09.2014 12:26, schrieb Suliman:

 I thought that new version of DUB will bring SDL instead json ...


That's planned for 1.0.0 (or a possible intermediate release). The major 
reason for this release is to get the new version management out as soon 
as possible, because it is a "breaking" change (not breaking in 
practice, because it only adds deprecation warnings).
Sep 22 2014
parent reply "Suliman" <evermind live.ru> writes:
On Monday, 22 September 2014 at 10:34:29 UTC, Sönke Ludwig wrote:

 Am 22.09.2014 12:26, schrieb Suliman:

 I thought that new version of DUB will bring SDL instead json 
 ...


 That's planned for 1.0.0 (or a possible intermediate release). 
 The major reason for this release is to get the new version 
 management out as soon as possible, because it is a "breaking" 
 change (not breaking in practice, because it only adds 
 deprecation warnings).


So what config format format you decided to introduce in 1.0?
Sep 22 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 22.09.2014 12:43, schrieb Suliman:

 On Monday, 22 September 2014 at 10:34:29 UTC, Sönke Ludwig wrote:

 Am 22.09.2014 12:26, schrieb Suliman:

 I thought that new version of DUB will bring SDL instead json ...


 That's planned for 1.0.0 (or a possible intermediate release). The
 major reason for this release is to get the new version management out
 as soon as possible, because it is a "breaking" change (not breaking
 in practice, because it only adds deprecation warnings).


 So what config format format you decided to introduce in 1.0?


The implementation of an SDL based parser has already been started by 
Jonathan Marler [1], so this is still the plan.

[1]: https://github.com/D-Programming-Language/dub/pull/392
Sep 22 2014
prev sibling next sibling parent =?ISO-8859-15?Q?S=F6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Now also on reddit:
http://www.reddit.com/r/programming/comments/2h492i/as_of_0922_dub_is_now_ds_official_package_manager/
Sep 22 2014
prev sibling next sibling parent "Paul Z. Barsan" <paulz.barsan gmail.com> writes:
Great news !

I have a suggestion, not so important: add the subConfigurations 
field in the complex variant of dependencies.If you have an issue 
with a package, you will have to look in one place instead of two.

See the github issue for details:
https://github.com/D-Programming-Language/dub/issues/422
Sep 22 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 22/09/14 11:33, Sönke Ludwig wrote:


   - Improved dependency version handling scheme. Version upgrades are
     now explicit, with the current snapshot being stored in the
     "dub.selections.json" file. This is similar to how other popular
     systems, such as Bundler [3], work, but built into the core system.
     Committing "dub.selections.json" to the repository ensures that
     everyone gets the same (working) combination of dependency versions.


Awesome :D

-- 
/Jacob Carlborg
Sep 22 2014
prev sibling next sibling parent "ponce" <contact gam3sfrommars.fr> writes:
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:

 But even more important, I'm pleased to announce that DUB is 
 now officially developed as part of the D language ecosystem! 
 Based on the decision back during this year's DConf, the 
 repository has been migrated to the D-Programming-Language 
 organization on GitHub [1], and we are now working towards a 
 1.0.0 milestone [2] that is supposed to be ready for inclusion 
 into the official DMD installation package.


Yay!
Thanks for all the work on DUB. Integrating third-party libraries 
has become so easy and practical with it, it encourages more code 
reuse.
Sep 22 2014
prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d-announce writes:
On 22 September 2014 10:33, Sönke Ludwig
<digitalmars-d-announce puremagic.com> wrote:

  - Added general support for single-file compilation mode, as well as
    separate compile/link mode for GDC.


N.B:

All-at-once compilation has improved with GDC.  But you still have to
wait minutes rather than seconds for compilations to finish if you do
optimized builds.

Iain.
Sep 22 2014
parent reply "Suliman" <evermind live.ru> writes:
  - Added general support for single-file compilation mode, as 
 well as
    separate compile/link mode for GDC.




I do not see any mentions about this key at docs. Can I add it to 
dub.json?
Nov 13 2014
parent reply "Mathias LANG" <geod24 gmail.com> writes:
On Thursday, 13 November 2014 at 11:06:06 UTC, Suliman wrote:

 - Added general support for single-file compilation mode, as 
 well as
   separate compile/link mode for GDC.




 I do not see any mentions about this key at docs. Can I add it 
 to dub.json?


Nope. It must be specified from the command-line. The relevant 
option, `build-mode`, is accessible through `dub build --help` 
(or any of the command that subclass build).
Nov 13 2014
parent "olivier henley" <olivier.henley ubisoft.com> writes:
Congrathx!
Nov 13 2014
prev sibling next sibling parent Mathias Lang via Digitalmars-d-announce writes:
2014-09-22 15:31 GMT+02:00 Iain Buclaw via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com>:


 On 22 September 2014 10:33, S=C3=B6nke Ludwig
 <digitalmars-d-announce puremagic.com> wrote:

  - Added general support for single-file compilation mode, as well as
    separate compile/link mode for GDC.


 N.B:

 All-at-once compilation has improved with GDC.  But you still have to
 wait minutes rather than seconds for compilations to finish if you do
 optimized builds.

 Iain.


The focus was on allowing one to compile on a limited platform (compiled
vibe.d on a Raspberry Pi B, 512 Mos or RAM, no swap).
In order to be fast, we will have to implement proper dependency analysis
(currently all object file are rebuild when something change).
Sep 22 2014
prev sibling next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Sep 22, 2014 at 16:00:40 +0200, Mathias Lang via Digitalmars-d-announce
wrote:

 The focus was on allowing one to compile on a limited platform (compiled vibe.d
 on a Raspberry Pi B, 512 Mos or RAM, no swap).
 In order to be fast, we will have to implement proper dependency analysis
 (currently all object file are rebuild when something change).


FWIW, the CMake branch[1] Trent and I have been working on has this
support if you want something sooner.

--Ben

[1]https://github.com/trentforkert/CMake
Sep 22 2014
prev sibling next sibling parent reply Leandro Motta Barros via Digitalmars-d-announce writes:
Hello,

I've been using dub for a short time only, but one thing I wish is an
easier way to create a project generating different targets (say, two
executables and three dynamic libraries). I was able to do something like
this using sub-packages, but couldn't find a way to generated all targets
in a single run. I wished to just say something like 'dub build' and have
all targets updated.

I don't know if this usage is in the scope of dub, nor do I know if it
would require any breaking change, but you asked for desired changes, so
here it is :-)

Cheers,

LMB

PS: I generally enjoy dub! Thanks a lot for it!


On Mon, Sep 22, 2014 at 6:33 AM, S=F6nke Ludwig <
digitalmars-d-announce puremagic.com> wrote:


 After again a longer-than-anticipated wait, the next release of the DUB
 package and build manager is finally ready. This is a major milestone wit=


h

 some important changes in the way dependency versions are handled, making
 it more robust for a rapidly growing ecosystem. The number of available
 packages is now well above the 300 mark and keeps growing steadily:

 http://vibed.org/temp/dub-packages.png


 But even more important, I'm pleased to announce that DUB is now
 officially developed as part of the D language ecosystem! Based on the
 decision back during this year's DConf, the repository has been migrated =


to

 the D-Programming-Language organization on GitHub [1], and we are now
 working towards a 1.0.0 milestone [2] that is supposed to be ready for
 inclusion into the official DMD installation package.

 If you can think of any potentially important and especially
 backwards-incompatible changes/additions, please mention them (ideally as
 GitHub tickets), so that we can include them before the 1.0.0 release.


 Major changes and additions in 0.9.22 include:

  - Improved dependency version handling scheme. Version upgrades are
    now explicit, with the current snapshot being stored in the
    "dub.selections.json" file. This is similar to how other popular
    systems, such as Bundler [3], work, but built into the core system.
    Committing "dub.selections.json" to the repository ensures that
    everyone gets the same (working) combination of dependency versions.

  - Branch based dependencies (e.g. "~master") have been deprecated due
    to their destructive influence on the package ecosystem. See the
    wiki [4] for more information, including on the alternative
    approaches that are now supported.

  - Simple DustMite [5] integration. Using the "dub dustmite" command it
    is now possible to reduce bugs in DUB packages with ease, even in
    complex package hierarchies. The condition used for reduction can be
    specified in terms of exit code or as a regular expression on the
    output of either the compiler, linker, or final executable.

  - Added BASH and FISH shell completion scripts.

  - Added general support for single-file compilation mode, as well as
    separate compile/link mode for GDC.

  - Platform detection now also works when cross-compiling.

  - Added the "*" version specifier to match any version, and path based
    dependencies don't need to specify an explicit version anymore.


 As always, find the full list of changes in the change log [6] and
 download at:

 http://code.dlang.org/download


 [1]: https://github.com/D-Programming-Language/dub/
 [2]: https://github.com/D-Programming-Language/dub/
 issues?q=3Dis%3Aopen+is%3Aissue+milestone%3A1.0.0
 [3]: http://bundler.io/
 [4]: https://github.com/D-Programming-Language/dub/wiki/Version-managemen=


t

 [5]: https://github.com/CyberShadow/DustMite/wiki
 [6]: https://github.com/D-Programming-Language/dub/blob/
 master/CHANGELOG.md
Sep 22 2014
parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig rejectedsoftware.com> writes:
Am 22.09.2014 17:03, schrieb Leandro Motta Barros via 
Digitalmars-d-announce:

 Hello,

 I've been using dub for a short time only, but one thing I wish is an
 easier way to create a project generating different targets (say, two
 executables and three dynamic libraries). I was able to do something
 like this using sub-packages, but couldn't find a way to generated all
 targets in a single run. I wished to just say something like 'dub build'
 and have all targets updated.

 I don't know if this usage is in the scope of dub, nor do I know if it
 would require any breaking change, but you asked for desired changes, so
 here it is :-)


Definitely in scope. There is already a matching ticket, I just didn't 
have the time to implement it:
https://github.com/D-Programming-Language/dub/issues/97
Sep 22 2014
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 22.09.2014 11:33, schrieb Sönke Ludwig:

 After again a longer-than-anticipated wait, the next release of the DUB
 package and build manager is finally ready. This is a major milestone
 with some important changes in the way dependency versions are handled,
 making it more robust for a rapidly growing ecosystem. The number of
 available packages is now well above the 300 mark and keeps growing
 steadily:

 http://vibed.org/temp/dub-packages.png


 But even more important, I'm pleased to announce that DUB is now
 officially developed as part of the D language ecosystem! Based on the
 decision back during this year's DConf, the repository has been migrated
 to the D-Programming-Language organization on GitHub [1], and we are now
 working towards a 1.0.0 milestone [2] that is supposed to be ready for
 inclusion into the official DMD installation package.

 If you can think of any potentially important and especially
 backwards-incompatible changes/additions, please mention them (ideally
 as GitHub tickets), so that we can include them before the 1.0.0 release.


 Major changes and additions in 0.9.22 include:

   - Improved dependency version handling scheme. Version upgrades are
     now explicit, with the current snapshot being stored in the
     "dub.selections.json" file. This is similar to how other popular
     systems, such as Bundler [3], work, but built into the core system.
     Committing "dub.selections.json" to the repository ensures that
     everyone gets the same (working) combination of dependency versions.

   - Branch based dependencies (e.g. "~master") have been deprecated due
     to their destructive influence on the package ecosystem. See the
     wiki [4] for more information, including on the alternative
     approaches that are now supported.

   - Simple DustMite [5] integration. Using the "dub dustmite" command it
     is now possible to reduce bugs in DUB packages with ease, even in
     complex package hierarchies. The condition used for reduction can be
     specified in terms of exit code or as a regular expression on the
     output of either the compiler, linker, or final executable.

   - Added BASH and FISH shell completion scripts.

   - Added general support for single-file compilation mode, as well as
     separate compile/link mode for GDC.

   - Platform detection now also works when cross-compiling.

   - Added the "*" version specifier to match any version, and path based
     dependencies don't need to specify an explicit version anymore.


 As always, find the full list of changes in the change log [6] and
 download at:

 http://code.dlang.org/download


 [1]: https://github.com/D-Programming-Language/dub/
 [2]:
 https://github.com/D-Programming-Language/dub/issues?q=is%3Aopen+is%3Aissue+milestone%3A1.0.0

 [3]: http://bundler.io/
 [4]: https://github.com/D-Programming-Language/dub/wiki/Version-management
 [5]: https://github.com/CyberShadow/DustMite/wiki
 [6]: https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md



This is great. I have been using it on my toy projects since 
code.dlang.org came into existence.

Congratulations to everyone involved.

--
Paulo
Sep 22 2014
prev sibling next sibling parent reply "Gary Willoughby" <dev nomad.so> writes:
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:

Great thanks Sönke!
Sep 22 2014
parent "Suliman" <evermind live.ru> writes:
Is it's proper name DUB analog of CMake and other build tools 
from C world?
Sep 22 2014
prev sibling next sibling parent reply "tn" <no email.com> writes:
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:

 If you can think of any potentially important and especially 
 backwards-incompatible changes/additions, please mention them 
 (ideally as GitHub tickets), so that we can include them before 
 the 1.0.0 release.


What is the recommended way of versioning bindings? If the 
binding of the target library 1.2.3 is versioned as 1.2.3 and a 
bug is fixed in the binding (no change in the target library), 
how should the new version of the binding for target version 
1.2.3 be versioned? Using 1.2.4 is not an option because it 
potentially collides with the binding for the next version of the 
target.

Derelict [1] has solved this problem in a "clever" way, which 
allows leaving the least significant number for the binding 
[2][3]. Take for example the bindings for SDL [4]: Bindings for 
target version 2.0.1 are versioned as 1.1.0, 1.1.1, 1.1.2 and so 
on. Correspondingly, for target version 2.0.2, the binding 
versions are 1.2.0, 1.2.1 and so on. I guess, that for for target 
2.1.0, the binging would be versioned 2.0.0, 2.0.1, and so on. I 
think that this is quite confusing. Is there a better way?

[1] https://github.com/DerelictOrg
[2] http://dblog.aldacron.net/derelict-help/using-derelict/
[3] http://dblog.aldacron.net/important-derelictsdl2-updates/
[4] http://code.dlang.org/packages/derelict-sdl2
Sep 22 2014
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 22/09/14 23:04, tn wrote:


 What is the recommended way of versioning bindings? If the binding of
 the target library 1.2.3 is versioned as 1.2.3 and a bug is fixed in the
 binding (no change in the target library), how should the new version of
 the binding for target version 1.2.3 be versioned? Using 1.2.4 is not an
 option because it potentially collides with the binding for the next
 version of the target.


The problem is locking the version of the Dub package to the same 
version of the library the bindings are for. In you're example I would 
do something like "1.2.3+1.2.3". If you need fix a bug in the bindings 
you increment as usual to "1.2.4+1.2.3". Anything after the plus sign is 
basically metadata that is ignore by Dub

-- 
/Jacob Carlborg
Sep 22 2014
parent reply "tn" <no email.com> writes:
On Tuesday, 23 September 2014 at 06:22:27 UTC, Jacob Carlborg 
wrote:

 On 22/09/14 23:04, tn wrote:


 What is the recommended way of versioning bindings? If the 
 binding of
 the target library 1.2.3 is versioned as 1.2.3 and a bug is 
 fixed in the
 binding (no change in the target library), how should the new 
 version of
 the binding for target version 1.2.3 be versioned? Using 1.2.4 
 is not an
 option because it potentially collides with the binding for 
 the next
 version of the target.


 The problem is locking the version of the Dub package to the 
 same version of the library the bindings are for. In you're 
 example I would do something like "1.2.3+1.2.3". If you need 
 fix a bug in the bindings you increment as usual to 
 "1.2.4+1.2.3". Anything after the plus sign is basically 
 metadata that is ignore by Dub


In your suggestion, once version 1.2.4 of the target library is 
released, the first binding version targeting that would then be 
1.2.4+1.2.4 or 1.2.5+1.2.4 or what?

And more importantly, how can a user of the binding then depend 
on the latest binding version of a specific target library 
version (for example the latest bindings for 1.2.3)?
Sep 23 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-09-23 10:08, tn wrote:


 In your suggestion, once version 1.2.4 of the target library is
 released, the first binding version targeting that would then be
 1.2.4+1.2.4 or 1.2.5+1.2.4 or what?


If the previous binding version was 1.2.3+1.2.3 the next would be 
1.2.4+1.2.4. Just increment as usual. It could also be that the target 
library doesn't follow Semver and if it contains an API breaking change 
it would be 2.0.0+1.2.4.


 And more importantly, how can a user of the binding then depend on the
 latest binding version of a specific target library version (for example
 the latest bindings for 1.2.3)?


Hmm, that's tricky. I don't have a good solution for that. It's easy to 
see if you look at all the versions. Just pick the highest version with 
the matching version after the plus.

-- 
/Jacob Carlborg
Sep 23 2014
prev sibling parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Mon, Sep 22, 2014 at 21:04:24 +0000, tn via Digitalmars-d-announce wrote:

 What is the recommended way of versioning bindings? If the 
 binding of the target library 1.2.3 is versioned as 1.2.3 and a 
 bug is fixed in the binding (no change in the target library), 
 how should the new version of the binding for target version 
 1.2.3 be versioned? Using 1.2.4 is not an option because it 
 potentially collides with the binding for the next version of the 
 target.


What about 1.2.3.x? How does dub handle letters in version numbers?
Maybe "1.2.3.0w" would be viable ('w' for 'wrap').

--Ben
Sep 25 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
On 25/09/14 21:38, Ben Boeckel via Digitalmars-d-announce wrote:


 What about 1.2.3.x? How does dub handle letters in version numbers?
 Maybe "1.2.3.0w" would be viable ('w' for 'wrap').


I don't think that's allowed. Dub's following this versioning scheme: 
http://semver.org/

-- 
/Jacob Carlborg
Sep 25 2014
prev sibling parent reply "Dragos Carp" <dragoscarp gmail.com> writes:
On Thursday, 25 September 2014 at 19:38:47 UTC, Ben Boeckel via 
Digitalmars-d-announce wrote:

 What about 1.2.3.x? How does dub handle letters in version 
 numbers?
 Maybe "1.2.3.0w" would be viable ('w' for 'wrap').


1.2.3.x is an invalid version number. Only 3 group numbers are 
allowed [1]. Though you could use prerelease and/or build 
suffixes (1.2.3-0w / 1.2.3+0w).


[1] - www.semver.org
Sep 25 2014
next sibling parent reply "tn" <no email.com> writes:
On Friday, 26 September 2014 at 06:29:21 UTC, Dragos Carp wrote:

 Though you could use prerelease and/or build suffixes (1.2.3-0w 
 / 1.2.3+0w).


These are very close to what I would like to see.

Though, if I understand correctly, build suffix wouldn't work, as 
for example 1.2.3+0w and 1.2.3+1w would be treated as equal: 
"Build metadata SHOULD be ignored when determining version 
precedence. Thus two versions that differ only in the build 
metadata, have the same precedence." (semver.org)

I guess that prerelease suffixes would do the trick. The only 
problem is conceptual: "A pre-release version indicates that the 
version is unstable and might not satisfy the intended 
compatibility requirements as denoted by its associated normal 
version." (semver.org)
Sep 26 2014
parent "Dragos Carp" <dragoscarp gmail.com> writes:
On Friday, 26 September 2014 at 08:37:12 UTC, tn wrote:

 On Friday, 26 September 2014 at 06:29:21 UTC, Dragos Carp wrote:

 Though you could use prerelease and/or build suffixes 
 (1.2.3-0w / 1.2.3+0w).


 These are very close to what I would like to see.

 Though, if I understand correctly, build suffix wouldn't work, 
 as for example 1.2.3+0w and 1.2.3+1w would be treated as equal: 
 "Build metadata SHOULD be ignored when determining version 
 precedence. Thus two versions that differ only in the build 
 metadata, have the same precedence." (semver.org)

 I guess that prerelease suffixes would do the trick. The only 
 problem is conceptual: "A pre-release version indicates that 
 the version is unstable and might not satisfy the intended 
 compatibility requirements as denoted by its associated normal 
 version." (semver.org)


In semver library [1], the differences in build suffixes are a) 
"right" ordered (defined sort order) and not equal, and b) 
considered compatible.

a) SemVer("1.2.3+w.9") < SemVer("1.2.3+w.10")
    SemVer("1.2.3+w.9") != SemVer("1.2.3+w.10")

b) SemVer("1.2.3+w.9").satisfies(SemVerRange("1.2.3"))
    SemVer("1.2.3+w.10").satisfies(SemVerRange("1.2.3"))
    SemVer("1.2.3+w.9").differAt(SemVer("1.0.0+w.10")) == 
VersionPart.BUILD


[1] http://code.dlang.org/packages/semver
Sep 26 2014
prev sibling parent reply Ben Boeckel via Digitalmars-d-announce writes:
On Fri, Sep 26, 2014 at 06:29:19 +0000, Dragos Carp via Digitalmars-d-announce
wrote:

 1.2.3.x is an invalid version number. Only 3 group numbers are 
 allowed [1]. Though you could use prerelease and/or build 
 suffixes (1.2.3-0w / 1.2.3+0w).


How would you version a library which wraps another with 4 version
components? Enforced semver to the limit that only 3 components are
supported seems a little heavy-handed to me.

--Ben
Oct 02 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 02.10.2014 14:27, schrieb Ben Boeckel via Digitalmars-d-announce:

 On Fri, Sep 26, 2014 at 06:29:19 +0000, Dragos Carp via Digitalmars-d-announce
wrote:

 1.2.3.x is an invalid version number. Only 3 group numbers are
 allowed [1]. Though you could use prerelease and/or build
 suffixes (1.2.3-0w / 1.2.3+0w).


 How would you version a library which wraps another with 4 version
 components? Enforced semver to the limit that only 3 components are
 supported seems a little heavy-handed to me.

 --Ben


The idea is to have an interoperable standard - modifying it in any way 
would break that, so that we could as well completely invent our own 
standard.

The way I see it is that the binding should be considered as 
individually versioned. It should usually start at 1.0.0 (maybe X.0.0, 
where X is the major version of the wrapped library, if that makes sense 
for the original version scheme) and be incremented purely according to 
SemVer. The version of the wrapped library can be documented as build 
metadata, but that's it.

To me a big argument against supporting something non-standard, such as 
a fourth version digit is that it facilitates blindly adopting a 
libraries original version scheme, even if that may work in a completely 
different way w.r.t. major, minor and patch versions.

But the idea of SemVer is that you can safely specify a version range 
such as 1.2.x and be sure to only get bugfixes, or 1.x.x and only get 
backwards compatible changes. Many other schemes don't have such 
guarantees, so directly translating them would be the a step to chaos.
Oct 04 2014
prev sibling next sibling parent reply "K.K." <trampzy yahoo.com> writes:
This inclusion into the DMD install, is just that DMD comes with
the dub.exe and .dll's (and ofcourse the linux & mac equivalents)
in it's folders, correct?
Sep 22 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 23.09.2014 03:50, schrieb K.K.:

 This inclusion into the DMD install, is just that DMD comes with
 the dub.exe and .dll's (and ofcourse the linux & mac equivalents)
 in it's folders, correct?


Yes, that's it basically.
Sep 23 2014
prev sibling next sibling parent Jordi Sayol via Digitalmars-d-announce writes:
Congratulations for this new release!

"dub" v0.9.22 deb package already available on "d-apt"
<http://d-apt.sourceforge.net/>.

This new deb package includes "dub" auto-completion script.

Regards,
-- 
Jordi Sayol
Sep 23 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
Arch Linux package has been updated. Does not include 
auto-completion right now, will do a point release with it 
soon-ish
Sep 23 2014
prev sibling parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
Thanks for your works,

One question, what about makefile support ?

Regards
Oct 06 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 06.10.2014 13:36, schrieb bioinfornatics:

 Thanks for your works,

 One question, what about makefile support ?

 Regards


It's still in need for a volunteer. The implementation itself should be 
pretty straightforward (by inheriting from the ProjectGenerator class), 
but I currently have too much higher priority stuff on my table to get 
that done (plus generally severely limited time due to an accumulation 
of work and non-work related things).
Oct 06 2014
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 10/06/2014 02:15 PM, Sönke Ludwig wrote:

 Am 06.10.2014 13:36, schrieb bioinfornatics:

 Thanks for your works,

 One question, what about makefile support ?

 Regards


 It's still in need for a volunteer. The implementation itself should be
 pretty straightforward (by inheriting from the ProjectGenerator class),
 but I currently have too much higher priority stuff on my table to get
 that done (plus generally severely limited time due to an accumulation
 of work and non-work related things).


I don't suppose there's documentation on the ProjectGenerator class? I 
was (briefly) looking into subclassing that for a "compiler cmdline 
args" output that I think would be helpful, but based on a (again, 
rather brief) glance at and its subclasses I had some trouble grokking 
how it worked. I'll have to take a look again though.
Oct 06 2014
parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 06.10.2014 23:14, schrieb Nick Sabalausky:

 On 10/06/2014 02:15 PM, Sönke Ludwig wrote:

 Am 06.10.2014 13:36, schrieb bioinfornatics:

 Thanks for your works,

 One question, what about makefile support ?

 Regards


 It's still in need for a volunteer. The implementation itself should be
 pretty straightforward (by inheriting from the ProjectGenerator class),
 but I currently have too much higher priority stuff on my table to get
 that done (plus generally severely limited time due to an accumulation
 of work and non-work related things).


 I don't suppose there's documentation on the ProjectGenerator class? I
 was (briefly) looking into subclassing that for a "compiler cmdline
 args" output that I think would be helpful, but based on a (again,
 rather brief) glance at and its subclasses I had some trouble grokking
 how it worked. I'll have to take a look again though.


That would actually be a nice example generator. I've now added initial 
documentation to the Generator class.
Oct 07 2014
parent "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
On Tuesday, 7 October 2014 at 08:36:37 UTC, Sönke Ludwig wrote:

 Am 06.10.2014 23:14, schrieb Nick Sabalausky:

 On 10/06/2014 02:15 PM, Sönke Ludwig wrote:

 Am 06.10.2014 13:36, schrieb bioinfornatics:

 Thanks for your works,

 One question, what about makefile support ?

 Regards


 It's still in need for a volunteer. The implementation itself 
 should be
 pretty straightforward (by inheriting from the 
 ProjectGenerator class),
 but I currently have too much higher priority stuff on my 
 table to get
 that done (plus generally severely limited time due to an 
 accumulation
 of work and non-work related things).


 I don't suppose there's documentation on the ProjectGenerator 
 class? I
 was (briefly) looking into subclassing that for a "compiler 
 cmdline
 args" output that I think would be helpful, but based on a 
 (again,
 rather brief) glance at and its subclasses I had some trouble 
 grokking
 how it worked. I'll have to take a look again though.


 That would actually be a nice example generator. I've now added 
 initial documentation to the Generator class.



Thanks I will continue to look "how to add makefile supprt?" 
after my job time.
Oct 07 2014
prev sibling parent reply "bioinfornatics" <bioinfornatics fedoraproject.org> writes:
On Monday, 6 October 2014 at 18:15:08 UTC, Sönke Ludwig wrote:

 Am 06.10.2014 13:36, schrieb bioinfornatics:

 Thanks for your works,

 One question, what about makefile support ?

 Regards


 It's still in need for a volunteer. The implementation itself 
 should be pretty straightforward (by inheriting from the 
 ProjectGenerator class), but I currently have too much higher 
 priority stuff on my table to get that done (plus generally 
 severely limited time due to an accumulation of work and 
 non-work related things).


I take a look but without a hacker doc that is not easy. So I
have some question ( do nott blame me )

---------------
why class who inherit from ProjectGenerator:
- should to get PackageManager as parameter in ctor (1) while
Project(2) struct has a PackageManager. Project struct is send
too in the ctor.

1)
https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/build.d#L39
2)
https://github.com/D-Programming-Language/dub/blob/master/source/dub/project.d#L39

---------------
why method:
generateTargets( in GeneratorSettings settings, in
TargetInfo[string] targets)

take an associative array of targets always you use only one
target named m_project.rootPackage.name

---------------
why you assign project (3) this is  not done when super is called
(4)?
3)
https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/build.d#L42
4)
https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/generator.d#L48

thanks
Oct 06 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 07.10.2014 01:35, schrieb bioinfornatics:

 On Monday, 6 October 2014 at 18:15:08 UTC, Sönke Ludwig wrote:

 Am 06.10.2014 13:36, schrieb bioinfornatics:

 Thanks for your works,

 One question, what about makefile support ?

 Regards


 It's still in need for a volunteer. The implementation itself should
 be pretty straightforward (by inheriting from the ProjectGenerator
 class), but I currently have too much higher priority stuff on my
 table to get that done (plus generally severely limited time due to an
 accumulation of work and non-work related things).


 I take a look but without a hacker doc that is not easy. So I
 have some question ( do nott blame me )


Yeah, sorry about that, the API documentation (and parts of the API 
itself) definitely need some work. So far the focus has been mostly on 
getting the functionality done and parts of the code are not ready to be 
considered clean library code.


 ---------------
 why class who inherit from ProjectGenerator:
 - should to get PackageManager as parameter in ctor (1) while
 Project(2) struct has a PackageManager. Project struct is send
 too in the ctor.

 1)
 https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/build.d#L39

 2)
 https://github.com/D-Programming-Language/dub/blob/master/source/dub/project.d#L39


I think this is mostly historically grown and Project could instead have 
a "packageManager" getter property.


 ---------------
 why method:
 generateTargets( in GeneratorSettings settings, in
 TargetInfo[string] targets)

 take an associative array of targets always you use only one
 target named m_project.rootPackage.name


The "targets" AA is also used in buildTargetRec(), which in turn goes 
recursively through the dependency graph and queries all of the targets.


 ---------------
 why you assign project (3) this is  not done when super is called
 (4)?
 3)
 https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/build.d#L42

 4)
 https://github.com/D-Programming-Language/dub/blob/master/source/dub/generators/generator.d#L48


That's just garbage left over from a refactoring. I'll remove the 
m_project field in BuildGenerator.
Oct 07 2014