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, Snke 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 Snke 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