Re: Release DUB 1.0.0
Am 23.06.2016 um 22:49 schrieb Basile B.: Do "single-file packages" have a special name, ie official, e.g if I want to add a menu item for this ? - Compile and run single file DUB package - Compile and run monolithic DUB package - ? I also think to "runnable DUB module" or "DUBable module" I've just always used "single-file DUB package" and didn't really consider alternatives so far. Something in the direction of "DUB script" would be another possibility.
Re: Release DUB 1.0.0
On Thursday, 23 June 2016 at 20:49:23 UTC, Basile B. wrote: Do "single-file packages" have a special name, ie official, e.g if I want to add a menu item for this ? - Compile and run single file DUB package - Compile and run monolithic DUB package - ? I also think to "runnable DUB module" or "DUBable module" That's obviously a DUBious module ;)
Re: Release DUB 1.0.0
On Wednesday, 22 June 2016 at 10:18:01 UTC, Sönke Ludwig wrote: Am 21.06.2016 um 00:37 schrieb Basile B.: You should add a system to support example files, without dependency. For example in a static library, something that would indicate that the package in which the file resides is itself a dependency but don't have to be downloaded: package examples ex1.d ex2.d source package src1.d ex1.d /+ dub.sdl: name "package" dependency "this" (or dependency "../..") +/ from ex1 you should be able to locate the package by using .dirName until a dub.json is found. Maybe that if the dep value is a relative path that leads to a description this works too. This currently works using dependency "package" path="../../" I'd like to avoid making this smarter, because currently (sub) packages are all logically distinct, which helps a lot to keep the internal logic simple in various places. An exception to this rule is that versions of sub packages are locked to the version of the parent package, which causes quite some complications in the dependency resolution algorithm, which in turn has often been a source of bugs. Do "single-file packages" have a special name, ie official, e.g if I want to add a menu item for this ? - Compile and run single file DUB package - Compile and run monolithic DUB package - ? I also think to "runnable DUB module" or "DUBable module"
Re: Release DUB 1.0.0
Am 21.06.2016 um 00:37 schrieb Basile B.: You should add a system to support example files, without dependency. For example in a static library, something that would indicate that the package in which the file resides is itself a dependency but don't have to be downloaded: package examples ex1.d ex2.d source package src1.d ex1.d /+ dub.sdl: name "package" dependency "this" (or dependency "../..") +/ from ex1 you should be able to locate the package by using .dirName until a dub.json is found. Maybe that if the dep value is a relative path that leads to a description this works too. This currently works using dependency "package" path="../../" I'd like to avoid making this smarter, because currently (sub) packages are all logically distinct, which helps a lot to keep the internal logic simple in various places. An exception to this rule is that versions of sub packages are locked to the version of the parent package, which causes quite some complications in the dependency resolution algorithm, which in turn has often been a source of bugs.
Re: Release DUB 1.0.0
Am 22.06.2016 um 11:51 schrieb gleb: Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that Hello! That's great! But... Is "DFLAGS="-defaultlib=libphobos2.so" dub build" still the only way to build dynamically linked binaries? What about standard options to build/link against ".so's"? Thank You! Do you mean building a shared library, or linking against the shared version of Phobos? The former case should automatically add -defaultlib, if targetType is set to "dynamicLibrary" in the package recipe. In the latter case, it has to be specified dynamically. Using DFLAGS is a possibility, or putting it in the "dflags" field of the recipe.
Re: Release DUB 1.0.0
Sönke Ludwig wrote: > I'm pleased to announce the release of the first stable version of the > DUB package manager. Stable in this case means that Hello! That's great! But... Is "DFLAGS="-defaultlib=libphobos2.so" dub build" still the only way to build dynamically linked binaries? What about standard options to build/link against ".so's"? Thank You!
Re: Release DUB 1.0.0
On Tuesday, 21 June 2016 at 10:57:45 UTC, Saurabh Das wrote: On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. [...] Congratulations on v1.0.0 and thank you for making and maintaining DUB! :) Saurabh +10
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. [...] Congratulations on v1.0.0 and thank you for making and maintaining DUB! :) Saurabh
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. [...] Congrats - this is great stuff!
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 19:45:29 UTC, Dechcaudron wrote: On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Congratulations and thank you from all of us! DUB is amazing!!! Me too :-)!
Re: Release DUB 1.0.0
On 2016-06-20 21:28, Sönke Ludwig wrote: I mostly just wanted to keep the DEP small and focused, but adding Objective-C/C++ is indeed trivial once C/C++ is there (modulo some small additional features). Ok, cool. -- /Jacob Carlborg
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: [...] This release also adds support for single-file packages, which can be used for conveniently writing small scripts and applications. It supports a shebang line, so that directly executing the script on Posix systems also works (using "chmod +x"): #!/usr/bin/env dub /+ dub.sdl: name "colortest" dependency "color" version="~>0.0.3" +/ You should add a system to support example files, without dependency. For example in a static library, something that would indicate that the package in which the file resides is itself a dependency but don't have to be downloaded: package examples ex1.d ex2.d source package src1.d ex1.d /+ dub.sdl: name "package" dependency "this" (or dependency "../..") +/ from ex1 you should be able to locate the package by using .dirName until a dub.json is found. Maybe that if the dep value is a relative path that leads to a description this works too.
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Congratulations and thank you from all of us! DUB is amazing!!!
Re: Release DUB 1.0.0
Am 20.06.2016 um 21:11 schrieb Jacob Carlborg: On 2016-06-20 17:52, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. Great work :) The main (high-level) priority for the upcoming versions will be adding C family language build support (starting with C/C++ and ObjC). There is a draft for how such support might look like, for anyone interested in discussing this in prior: https://github.com/dlang/dub/wiki/DEP5 The DEP explicitly mentions Objective-C as not part of the DEP. But above you're mentioning Objective-C? It should be just as easy to support Objective-C and Objective-C++ as well from the perspective of the tool. For Objective-C it's basically the C compiler but with .m files and for Objective-C++ it's the C++ compiler but with .mm files. I mostly just wanted to keep the DEP small and focused, but adding Objective-C/C++ is indeed trivial once C/C++ is there (modulo some small additional features).
Re: Release DUB 1.0.0
On 2016-06-20 17:52, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. Great work :) The main (high-level) priority for the upcoming versions will be adding C family language build support (starting with C/C++ and ObjC). There is a draft for how such support might look like, for anyone interested in discussing this in prior: https://github.com/dlang/dub/wiki/DEP5 The DEP explicitly mentions Objective-C as not part of the DEP. But above you're mentioning Objective-C? It should be just as easy to support Objective-C and Objective-C++ as well from the perspective of the tool. For Objective-C it's basically the C compiler but with .m files and for Objective-C++ it's the C++ compiler but with .mm files. -- /Jacob Carlborg
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Congrats! Can't wait to see DUB bundled with DMD.
Re: Release DUB 1.0.0
On Monday, 20 June 2016 at 15:52:46 UTC, Sönke Ludwig wrote: I'm pleased to announce the release of the first stable version of the DUB package manager. Stable in this case means that the API, the command line interface and the package recipe format will only receive fully backwards compatible changes and additions for a while. [...] Congratulations on the 1.0.0 release, and thanks for providing this tool to the community.
