digitalmars.D - Will this features be accepted for DUB?

Ilya Yaroshenko (17/17) Dec 16 2016 Mir GLAS should be builded with special dub flags, in the future

rikki cattermole (6/14) Dec 16 2016 Sure, preGenerateCommands/preBuildCommands.

Ilya Yaroshenko (17/36) Dec 16 2016 Mir needs different project be builded in deferent modes.

Guillaume Piolat (28/39) Dec 16 2016 Trying to answer with the existing dub.

Ilya Yaroshenko (19/58) Dec 16 2016 This approach does not work for Mir GLAS.

drug (6/23) Dec 16 2016 You can link mir-glas as binary lib, not source one, so there is no this...
Joseph Rushton Wakeling (5/7) Dec 16 2016 It sounds like what is really needed here is the ability to
John Colvin (17/92) Dec 16 2016 Do you actually mean extern(C) or extern(D)? You said both at

John Colvin (6/24) Dec 16 2016 Of course mir-glas-impl could be a subconfiguration, or a
Ilya Yaroshenko (3/21) Dec 16 2016 GLAS has extern(C) interface with D aliases.
jmh530 (3/18) Dec 16 2016 It might make sense to provide a sample dub.json file with mir to

John Colvin (4/26) Dec 16 2016 That stuff would be in mir-glas's dub.{json,sdl}, end users would

Ilya Yaroshenko (4/13) Dec 16 2016 Done,

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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

Dec 16 2016

rikki cattermole <rikki cattermole.co.nz> writes:

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.

Dec 16 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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?

Dec 16 2016

Guillaume Piolat <first.last gmail.com> writes:

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.

Dec 16 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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

Dec 16 2016

drug <drug2004 bk.ru> writes:

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

Dec 16 2016

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

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

Dec 16 2016

John Colvin <john.loughran.colvin gmail.com> writes:

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)

Dec 16 2016

John Colvin <john.loughran.colvin gmail.com> writes:

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

Dec 16 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

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

Dec 16 2016

jmh530 <john.michael.hall gmail.com> writes:

On Friday, 16 December 2016 at 17:21:13 UTC, John Colvin 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)

It might make sense to provide a sample dub.json file with mir to 
make user's lives easier.

Dec 16 2016

John Colvin <john.loughran.colvin gmail.com> writes:

On Friday, 16 December 2016 at 19:14:39 UTC, jmh530 wrote:
 On Friday, 16 December 2016 at 17:21:13 UTC, John Colvin 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)

 It might make sense to provide a sample dub.json file with mir 
 to make user's lives easier.

That stuff would be in mir-glas's dub.{json,sdl}, end users would 
just depend on mir-glas like any other package and wouldn't have 
to worry about any of this.

Dec 16 2016

Ilya Yaroshenko <ilyayaroshenko gmail.com> writes:

On Friday, 16 December 2016 at 21:35:23 UTC, John Colvin wrote:
 On Friday, 16 December 2016 at 19:14:39 UTC, jmh530 wrote:
 On Friday, 16 December 2016 at 17:21:13 UTC, John Colvin wrote:
 [...]

 It might make sense to provide a sample dub.json file with mir 
 to make user's lives easier.

 That stuff would be in mir-glas's dub.{json,sdl}, end users 
 would just depend on mir-glas like any other package and 
 wouldn't have to worry about any of this.

Done, 
http://forum.dlang.org/post/nbsoerzljyxznxetgtji forum.dlang.org
Thank you!

Dec 16 2016

D Programming

C/C++ Programming

Other

digitalmars.D - Will this features be accepted for DUB?