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

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

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!

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.

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.

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"

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 ;)

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.