Re: DUB 0.9.22 released
- 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?
Re: DUB 0.9.22 released
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).
Re: DUB 0.9.22 released
Congrathx!
Re: DUB 0.9.22 released
Thanks for your works, One question, what about makefile support ? Regards
Re: DUB 0.9.22 released
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).
Re: DUB 0.9.22 released
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.
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
Am 02.10.2014 14:27, schrieb Ben Boeckel via Digitalmars-d-announce: On Fri, Sep 26, 2014 at 06:29:19 +, 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.
Re: DUB 0.9.22 released
On Fri, Sep 26, 2014 at 06:29:19 +, 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
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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)
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
On Mon, Sep 22, 2014 at 21:04:24 +, 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
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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.
Re: DUB 0.9.22 released
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)?
Re: DUB 0.9.22 released
Arch Linux package has been updated. Does not include auto-completion right now, will do a point release with it soon-ish
Re: DUB 0.9.22 released
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
DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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: 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.
Re: DUB 0.9.22 released
I thought that new version of DUB will bring SDL instead json ...
Re: DUB 0.9.22 released
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).
Re: DUB 0.9.22 released
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?
Re: DUB 0.9.22 released
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.
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
Now also on reddit: http://www.reddit.com/r/programming/comments/2h492i/as_of_0922_dub_is_now_ds_official_package_manager/
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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.
Re: DUB 0.9.22 released
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.
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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?
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote: Great thanks Sönke!
Re: DUB 0.9.22 released
Is it's proper name DUB analog of CMake and other build tools from C world?
Re: DUB 0.9.22 released
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.
Re: DUB 0.9.22 released
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
Re: DUB 0.9.22 released
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?
