www.digitalmars.com         C & C++   DMDScript  

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

reply 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
next sibling parent reply 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
parent 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
prev sibling parent reply 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
parent reply 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
next sibling parent 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
prev sibling next sibling parent 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
prev sibling parent reply 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
next sibling parent 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
prev sibling next sibling parent 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
prev sibling parent reply 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
parent reply 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
parent 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