DUB 0.9.22 released

[Sönke Ludwig via Digitalmars-d-announce]

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:

Loading Image...


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

[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 <

Post by Sönke Ludwig via Digitalmars-d-announce
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20140922/08c3f7f5/attachment.html>

[Suliman via Digitalmars-d-announce]

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

[Sönke Ludwig via Digitalmars-d-announce]

Post by Suliman via Digitalmars-d-announce
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).

[Suliman via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce

Post by Suliman via Digitalmars-d-announce
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?

[Sönke Ludwig via Digitalmars-d-announce]

Post by Suliman via Digitalmars-d-announce

Post by Sönke Ludwig via Digitalmars-d-announce

Post by Suliman via Digitalmars-d-announce
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

[Sönke Ludwig via Digitalmars-d-announce]

Post by 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 at 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.

Post by Mathias Lang via Digitalmars-d-announce
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.

[Jacob Carlborg via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce
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.

[Poyeyo via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce
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?

[Sönke Ludwig via Digitalmars-d-announce]

Post by Poyeyo via Digitalmars-d-announce

Post by Sönke Ludwig via Digitalmars-d-announce
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.

[Sönke Ludwig via Digitalmars-d-announce]

Now also on reddit:
http://www.reddit.com/r/programming/comments/2h492i/as_of_0922_dub_is_now_ds_official_package_manager/

[Paul Z. Barsan via Digitalmars-d-announce]

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

[Jacob Carlborg via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce
- 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

[ponce via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce
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.

[Iain Buclaw via Digitalmars-d-announce]

On 22 September 2014 10:33, Sönke Ludwig

Post by Sönke Ludwig via Digitalmars-d-announce
- 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.

[Mathias Lang via Digitalmars-d-announce]

2014-09-22 15:31 GMT+02:00 Iain Buclaw via Digitalmars-d-announce <

Post by Iain Buclaw via Digitalmars-d-announce
On 22 September 2014 10:33, Sönke Ludwig

Post by Sönke Ludwig via Digitalmars-d-announce
- Added general support for single-file compilation mode, as well as
separate compile/link mode for GDC.

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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20140922/9b045590/attachment.html>

[Ben Boeckel via Digitalmars-d-announce]

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

[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 :-)

Cheers,

LMB

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


On Mon, Sep 22, 2014 at 6:33 AM, Sönke Ludwig <

Post by Sönke Ludwig via Digitalmars-d-announce
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
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.
- 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
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-announce/attachments/20140922/56901e66/attachment-0001.html>

[Sönke Ludwig via Digitalmars-d-announce]

Am 22.09.2014 17:03, schrieb Leandro Motta Barros via

Post by 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

[Paulo Pinto via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce
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
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.
- 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
http://code.dlang.org/download
[1]: https://github.com/D-Programming-Language/dub/
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

[Gary Willoughby via Digitalmars-d-announce]

On Monday, 22 September 2014 at 09:33:52 UTC, Sönke Ludwig wrote:

Great thanks Sönke!

[Suliman via Digitalmars-d-announce]

Is it's proper name DUB analog of CMake and other build tools
from C world?

[tn via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce
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

[Jacob Carlborg via Digitalmars-d-announce]

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

[tn via Digitalmars-d-announce]

On Tuesday, 23 September 2014 at 06:22:27 UTC, Jacob Carlborg

Post by Jacob Carlborg via Digitalmars-d-announce

Post by tn via Digitalmars-d-announce
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)?

[Jacob Carlborg via Digitalmars-d-announce]

Post by tn via Digitalmars-d-announce
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.

Post by tn via Digitalmars-d-announce
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.

[Ben Boeckel via Digitalmars-d-announce]

Post by tn via Digitalmars-d-announce
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

[Jacob Carlborg via Digitalmars-d-announce]

Post by Ben Boeckel via Digitalmars-d-announce
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/

[Dragos Carp via Digitalmars-d-announce]

On Thursday, 25 September 2014 at 19:38:47 UTC, Ben Boeckel via

Post by Ben Boeckel via Digitalmars-d-announce
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

[tn via Digitalmars-d-announce]

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)

[Dragos Carp via Digitalmars-d-announce]

Post by tn via Digitalmars-d-announce

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

[Ben Boeckel via Digitalmars-d-announce]

Post by Dragos Carp via Digitalmars-d-announce
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

[Sönke Ludwig via Digitalmars-d-announce]

Post by Ben Boeckel via Digitalmars-d-announce

Post by Dragos Carp via Digitalmars-d-announce
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.

[K.K. via Digitalmars-d-announce]

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?

[Sönke Ludwig via Digitalmars-d-announce]

Post by K.K. via Digitalmars-d-announce
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.

[Jordi Sayol via Digitalmars-d-announce]

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,

[Dicebot via Digitalmars-d-announce]

Arch Linux package has been updated. Does not include
auto-completion right now, will do a point release with it
soon-ish

[bioinfornatics via Digitalmars-d-announce]

Thanks for your works,

One question, what about makefile support ?

Regards

[Sönke Ludwig via Digitalmars-d-announce]

Post by bioinfornatics via Digitalmars-d-announce
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).

[Nick Sabalausky via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce

Post by bioinfornatics via Digitalmars-d-announce
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.

[Sönke Ludwig via Digitalmars-d-announce]

Post by Nick Sabalausky via Digitalmars-d-announce

Post by Sönke Ludwig via Digitalmars-d-announce

Post by bioinfornatics via Digitalmars-d-announce
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.

[bioinfornatics via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce

Post by Nick Sabalausky via Digitalmars-d-announce

Post by Sönke Ludwig via Digitalmars-d-announce

Post by bioinfornatics via Digitalmars-d-announce
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.

[bioinfornatics via Digitalmars-d-announce]

Post by Sönke Ludwig via Digitalmars-d-announce

Post by bioinfornatics via Digitalmars-d-announce
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

[Sönke Ludwig via Digitalmars-d-announce]

Post by bioinfornatics via Digitalmars-d-announce

Post by Sönke Ludwig via Digitalmars-d-announce

Post by bioinfornatics via Digitalmars-d-announce
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.

Post by bioinfornatics via Digitalmars-d-announce
---------------
- 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.

Post by bioinfornatics via Digitalmars-d-announce
---------------
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.

Post by bioinfornatics via Digitalmars-d-announce
---------------
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.