Mir GLAS should be builded with special dub flags, in the future it will require to be linked with netlib libs.

We need
1. a post fetch (build) options. GLAS should be builded only in release, and in single file mode. It is a betterC library with extern C interface.
2. ability to build C/C++ code, run makefiles.
3. ability to compose libraries.
4. ability to override a compiler for betterC libraries.

DUB allows to set only compiler flags. I want to define how betterC libraries should be builded inside their dub configs instead of unified compiler/build options for all libs like it works now.

Currently a user should build glas and copy it into his path. We want this work out of the box.

Will this featured be accepted?

Ilya

On 17/12/2016 2:21 AM, Ilya Yaroshenko wrote:
> Mir GLAS should be builded with special dub flags, in the future it will
> require to be linked with netlib libs.
>
> We need
> 1. a post fetch (build) options. GLAS should be builded only in release,
> and in single file mode. It is a betterC library with extern C interface.

I doubt that is going in, as that overrides what the user may want to do.

> 2. ability to build C/C++ code, run makefiles.

Sure, preGenerateCommands/preBuildCommands.

> 3. ability to compose libraries.

Umm what?

> 4. ability to override a compiler for betterC libraries.

It should be transitive meaning if a dependency specifies it, then all packages should have it. Which is a reasonable feature request.

Trying to answer with the existing dub.

On Friday, 16 December 2016 at 13:21:53 UTC, Ilya Yaroshenko wrote:
> We need
> 1. a post fetch (build) options. GLAS should be builded only in release, and in single file mode. It is a betterC library with extern C interface.

--combined -b release-nobounds


> 2. ability to build C/C++ code, run makefiles.

As Rikki said.

> 3. ability to compose libraries.

Not sure what you mean.

> 4. ability to override a compiler for betterC libraries.

Not sure what you mean. The selected compiler is outside the dub configurations with --compiler.
You probably know can have special LDC flags:


> DUB allows to set only compiler flags. I want to define how betterC libraries should be builded inside their dub configs instead of unified compiler/build options for all libs like it works now.

Dub configurations and dependencies sub-configurations let you define version identifiers from outside the library, and can have different "dflags" too.

Example from product:

----------------

        "configurations": [
        {
            "name": "VST-EE",
            "versions": ["VST", "full"],
            "targetType": "dynamicLibrary",
            "lflags-osx": [ "-exported_symbols_list", "source/module-vst.lst", "-dead_strip" ]
        },

----------------

The tricky thing is to recognize where "lflags" or "dflags" are needed, and how this interact with --combined (dflags and lflags get merged then).

Investment in dub pays dividend by being unified and makes sense after a while.

On Friday, 16 December 2016 at 13:28:49 UTC, rikki cattermole wrote:
> On 17/12/2016 2:21 AM, Ilya Yaroshenko wrote:
>> Mir GLAS should be builded with special dub flags, in the future it will
>> require to be linked with netlib libs.
>>
>> We need
>> 1. a post fetch (build) options. GLAS should be builded only in release,
>> and in single file mode. It is a betterC library with extern C interface.
>
> I doubt that is going in, as that overrides what the user may want to do.

Mir needs different project be builded in deferent modes.
For example GLAS requires
	--build-mode=singleFile --compiler=ldmd2.
Other package may require to be builded with other modes and other compiler. But a user program may use any compiler and compilation mode. This is possible for libraries with extern(C) interface.

>> 2. ability to build C/C++ code, run makefiles.
>
> Sure, preGenerateCommands/preBuildCommands.

This does not work for Mir GLAS. Mir GLAS should be builded as a C library with extern D interface.

preGenerateCommands/preBuildCommands generates different binaries for different compilation modes and different compilers which would not work for Mir GLAS.

>> 3. ability to compose libraries.
>
> Umm what?

For example: two project that should be linked into a single library.

>
>> 4. ability to override a compiler for betterC libraries.
>
> It should be transitive meaning if a dependency specifies it, then all packages should have it.

What do you mean?

On Friday, 16 December 2016 at 13:55:55 UTC, Guillaume Piolat wrote:
> Trying to answer with the existing dub.
>
> On Friday, 16 December 2016 at 13:21:53 UTC, Ilya Yaroshenko wrote:
>> We need
>> 1. a post fetch (build) options. GLAS should be builded only in release, and in single file mode. It is a betterC library with extern C interface.
>
> --combined -b release-nobounds
>
>> 2. ability to build C/C++ code, run makefiles.
>
> As Rikki said.
>
>> 3. ability to compose libraries.
>
> Not sure what you mean.
>
>> 4. ability to override a compiler for betterC libraries.
>
> Not sure what you mean. The selected compiler is outside the dub configurations with --compiler.
> You probably know can have special LDC flags:
>
>
>> DUB allows to set only compiler flags. I want to define how betterC libraries should be builded inside their dub configs instead of unified compiler/build options for all libs like it works now.
>
> Dub configurations and dependencies sub-configurations let you define version identifiers from outside the library, and can have different "dflags" too.
>
> Example from product:
>
> ----------------
>
>         "configurations": [
>         {
>             "name": "VST-EE",
>             "versions": ["VST", "full"],
>             "targetType": "dynamicLibrary",
>             "lflags-osx": [ "-exported_symbols_list", "source/module-vst.lst", "-dead_strip" ]
>         },
>
> ----------------
>
> The tricky thing is to recognize where "lflags" or "dflags" are needed, and how this interact with --combined (dflags and lflags get merged then).
>
> Investment in dub pays dividend by being unified and makes sense after a while.

This approach does not work for Mir GLAS.
http://forum.dlang.org/post/dfqcgdfnxmnkreywoyhl@forum.dlang.org

I can build a Mir GLAS library with DUB. But I can not do it automatically with DUB, but want to do it.

For example:
---
"dependencies": {
    "mir-glas": "<its recent version>"
}
---
will not work for a user because mir-glas should be prebuilded with the following command:

dub build --config=static --build=target-native --compiler=ldmd2 --build-mode=singleFile --parallel

And it should be builded this way whatever compiler and dub options user use for his project.

Ilya

16.12.2016 18:09, Ilya Yaroshenko пишет:
>
> This approach does not work for Mir GLAS.
> http://forum.dlang.org/post/dfqcgdfnxmnkreywoyhl@forum.dlang.org
>
> I can build a Mir GLAS library with DUB. But I can not do it
> automatically with DUB, but want to do it.
>
> For example:
> ---
> "dependencies": {
>     "mir-glas": "<its recent version>"
> }
> ---
> will not work for a user because mir-glas should be prebuilded with the
> following command:
You can link mir-glas as binary lib, not source one, so there is no this dependency at all.
In preBuilt phase you can check if mir-glas is recent and update+build it if no with the flags you needed. This way user will use your custom scripts for using mir-glass and dub for the rest.
>
> dub build --config=static --build=target-native --compiler=ldmd2
> --build-mode=singleFile --parallel
>
> And it should be builded this way whatever compiler and dub options user
> use for his project.
>
> Ilya

On Friday, 16 December 2016 at 15:09:02 UTC, Ilya Yaroshenko wrote:
> And it should be builded this way whatever compiler and dub options user use for his project.

It sounds like what is really needed here is the ability to specify default build choices in `dub.json` (which the user could then override if they had a reason to do so).

On Friday, 16 December 2016 at 15:09:02 UTC, Ilya Yaroshenko wrote:
> On Friday, 16 December 2016 at 13:55:55 UTC, Guillaume Piolat wrote:
>> Trying to answer with the existing dub.
>>
>> On Friday, 16 December 2016 at 13:21:53 UTC, Ilya Yaroshenko wrote:
>>> We need
>>> 1. a post fetch (build) options. GLAS should be builded only in release, and in single file mode. It is a betterC library with extern C interface.
>>
>> --combined -b release-nobounds
>>
>>> 2. ability to build C/C++ code, run makefiles.
>>
>> As Rikki said.
>>
>>> 3. ability to compose libraries.
>>
>> Not sure what you mean.
>>
>>> 4. ability to override a compiler for betterC libraries.
>>
>> Not sure what you mean. The selected compiler is outside the dub configurations with --compiler.
>> You probably know can have special LDC flags:
>>
>>
>>> DUB allows to set only compiler flags. I want to define how betterC libraries should be builded inside their dub configs instead of unified compiler/build options for all libs like it works now.
>>
>> Dub configurations and dependencies sub-configurations let you define version identifiers from outside the library, and can have different "dflags" too.
>>
>> Example from product:
>>
>> ----------------
>>
>>         "configurations": [
>>         {
>>             "name": "VST-EE",
>>             "versions": ["VST", "full"],
>>             "targetType": "dynamicLibrary",
>>             "lflags-osx": [ "-exported_symbols_list", "source/module-vst.lst", "-dead_strip" ]
>>         },
>>
>> ----------------
>>
>> The tricky thing is to recognize where "lflags" or "dflags" are needed, and how this interact with --combined (dflags and lflags get merged then).
>>
>> Investment in dub pays dividend by being unified and makes sense after a while.
>
> This approach does not work for Mir GLAS.
> http://forum.dlang.org/post/dfqcgdfnxmnkreywoyhl@forum.dlang.org
>
> I can build a Mir GLAS library with DUB. But I can not do it automatically with DUB, but want to do it.
>
> For example:
> ---
> "dependencies": {
>     "mir-glas": "<its recent version>"
> }
> ---
> will not work for a user because mir-glas should be prebuilded with the following command:
>
> dub build --config=static --build=target-native --compiler=ldmd2 --build-mode=singleFile --parallel
>
> And it should be builded this way whatever compiler and dub options user use for his project.
>
> Ilya

Do you actually mean extern(C) or extern(D)? You said both at different points in this thread.

Perhaps this will give you an idea to start from:

name "mir-glas"
sourcePaths "folderWithDiFiles"
importPaths "folderWithDiFiles"
targetType "sourceLibrary"
preBuildCommands "dub build mir-glas-impl --config=static --build=target-native --compiler=ldmd2 --build-mode=singleFile --parallel"
libs "mir-glas-impl"
lflags "-L$MIR_GLAS_IMPL_PACKAGE_DIR"

$MIR_GLAS_IMPL_PACKAGE_DIR is defined by dub, as described in the docs at https://code.dlang.org/package-format?lang=sdl (search for $<name>_PACKAGE_DIR)

On Friday, 16 December 2016 at 17:21:13 UTC, John Colvin wrote:
> On Friday, 16 December 2016 at 15:09:02 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> Do you actually mean extern(C) or extern(D)? You said both at different points in this thread.
>
> Perhaps this will give you an idea to start from:
>
> name "mir-glas"
> sourcePaths "folderWithDiFiles"
> importPaths "folderWithDiFiles"
> targetType "sourceLibrary"
> preBuildCommands "dub build mir-glas-impl --config=static --build=target-native --compiler=ldmd2 --build-mode=singleFile --parallel"
> libs "mir-glas-impl"
> lflags "-L$MIR_GLAS_IMPL_PACKAGE_DIR"
>
> $MIR_GLAS_IMPL_PACKAGE_DIR is defined by dub, as described in the docs at https://code.dlang.org/package-format?lang=sdl (search for $<name>_PACKAGE_DIR)

Of course mir-glas-impl could be a subconfiguration, or a subpackage or whatever so it's definitely fetched, I'm just trying to communicate that you can call dub in the preBuildCommands and then link to the resulting library using libs and lflags

On Friday, 16 December 2016 at 17:21:13 UTC, John Colvin wrote:
> On Friday, 16 December 2016 at 15:09:02 UTC, Ilya Yaroshenko wrote:
>> [...]
>
> Do you actually mean extern(C) or extern(D)? You said both at different points in this thread.
>
> Perhaps this will give you an idea to start from:
>
> name "mir-glas"
> sourcePaths "folderWithDiFiles"
> importPaths "folderWithDiFiles"
> targetType "sourceLibrary"
> preBuildCommands "dub build mir-glas-impl --config=static --build=target-native --compiler=ldmd2 --build-mode=singleFile --parallel"
> libs "mir-glas-impl"
> lflags "-L$MIR_GLAS_IMPL_PACKAGE_DIR"
>
> $MIR_GLAS_IMPL_PACKAGE_DIR is defined by dub, as described in the docs at https://code.dlang.org/package-format?lang=sdl (search for $<name>_PACKAGE_DIR)

GLAS has extern(C) interface with D aliases.

Thank you for the example! will try to implement your idea