digitalmars.D.learn - dub: Is it possible to have a library target and depend on it in the
- wjoe (16/16) Sep 18 2020 Something like this:
- Danny Arends (15/31) Sep 18 2020 yes just add 2 configurations, use mainSourceFile to specify the
- Mike Parker (15/31) Sep 18 2020 Yes, this is possible. Should be something like this:
- wjoe (11/46) Sep 18 2020 Awesome. Thanks. And Danny to you, too.
- Mike Parker (20/29) Sep 18 2020 You'll have to invoke dub once for each config. Just slap both
- wjoe (9/40) Sep 18 2020 I usually either specify the target as a dependency in meson and
- Steven Schveighoffer (21/42) Sep 18 2020 There are other options.
- wjoe (3/25) Sep 18 2020 A subproject. Interesting. this sounds like what I want to do.
Something like this: configuration "lib" { targetType "dynamicLibrary" sourceDir "source/lib/" } configuration "app" { targetType "executable" sourceFiles "source/app.d" linkWith "lib" } I found subConfiguration in the docs but that seems to be related to external dependencies. app.d merely provides a CLI to the library as well as an option to run as a server. I don't want to have the overhead of an entire git repo and such for something that is a single file and also closely related to the library.
Sep 18 2020
On Friday, 18 September 2020 at 11:38:14 UTC, wjoe wrote:Something like this: configuration "lib" { targetType "dynamicLibrary" sourceDir "source/lib/" } configuration "app" { targetType "executable" sourceFiles "source/app.d" linkWith "lib" } I found subConfiguration in the docs but that seems to be related to external dependencies. app.d merely provides a CLI to the library as well as an option to run as a server. I don't want to have the overhead of an entire git repo and such for something that is a single file and also closely related to the library.yes just add 2 configurations, use mainSourceFile to specify the file with main() "configurations": [ { "name": "default", "targetPath": "bin", "targetType": "executable", "mainSourceFile": "main/main.d" "sourcePaths": ["src/"], },{ "name": "lib", "targetType": "dynamicLibrary", "sourcePaths": ["src/"], }]
Sep 18 2020
On Friday, 18 September 2020 at 11:38:14 UTC, wjoe wrote:Something like this: configuration "lib" { targetType "dynamicLibrary" sourceDir "source/lib/" } configuration "app" { targetType "executable" sourceFiles "source/app.d" linkWith "lib" } I found subConfiguration in the docs but that seems to be related to external dependencies. app.d merely provides a CLI to the library as well as an option to run as a server. I don't want to have the overhead of an entire git repo and such for something that is a single file and also closely related to the library.Yes, this is possible. Should be something like this: configuration "lib" { targetType "dynamicLibrary" targetPath "lib" sourcePaths "source/lib/" excludedSourceFiles "source/app.d" } configuration "app" { targetType "executable" mainSourceFile "source/app.d" excludedSourceFiles "source/lib/*.d" importPaths "source/lib" libs "lib/libName" }
Sep 18 2020
On Friday, 18 September 2020 at 12:03:45 UTC, Mike Parker wrote:On Friday, 18 September 2020 at 11:38:14 UTC, wjoe wrote:Awesome. Thanks. And Danny to you, too. 2 issues though. - It doesn't build the library automatically, and - Linking fails because error: ld: cannot find -llib<name> Built it manually via dub --config=lib and it lives inside the lib directory. Then added lflags "-Llib" to the "app" configuration but that didn't help. ld still can't find the file. Then I passed the absolute path and ld still complains. Any ideas as to why ?Something like this: configuration "lib" { targetType "dynamicLibrary" sourceDir "source/lib/" } configuration "app" { targetType "executable" sourceFiles "source/app.d" linkWith "lib" } I found subConfiguration in the docs but that seems to be related to external dependencies. app.d merely provides a CLI to the library as well as an option to run as a server. I don't want to have the overhead of an entire git repo and such for something that is a single file and also closely related to the library.Yes, this is possible. Should be something like this: configuration "lib" { targetType "dynamicLibrary" targetPath "lib" sourcePaths "source/lib/" excludedSourceFiles "source/app.d" } configuration "app" { targetType "executable" mainSourceFile "source/app.d" excludedSourceFiles "source/lib/*.d" importPaths "source/lib" libs "lib/libName" }
Sep 18 2020
On Friday, 18 September 2020 at 12:28:30 UTC, wjoe wrote:2 issues though. - It doesn't build the library automatically, andYou'll have to invoke dub once for each config. Just slap both commands in a script.- Linking fails because error: ld: cannot find -llib<name> Built it manually via dub --config=lib and it lives inside the lib directory. Then added lflags "-Llib" to the "app" configuration but that didn't help. ld still can't find the file. Then I passed the absolute path and ld still complains. Any ideas as to why ?It's just a matter of getting the configuration right and making the linker happy. I don't think I've ever linked with anything other than system libraries on Linux, so I really don't know what it expects when linking with a custom shared library outside of the system path. Make sure that your library foo.so is named `libfoo.so`, when you pass the lib path along in dflags via -L, then make sure to change `libs "lib/foo"` to `libs "foo"`. The initial failure may be because of the path in the library name. I remember reading somewhere long ago that if you're passing a path in the library name (instead of using the -L flag), then you have to specify the full file name, e.g. lib/libfoo.so. I don't know if dub will pass that along correctly though. Whatever the case, trying adding -v to your dub command line so you can see exactly what's dub is calling the compiler with. That may give you a hint.
Sep 18 2020
On Friday, 18 September 2020 at 14:01:55 UTC, Mike Parker wrote:On Friday, 18 September 2020 at 12:28:30 UTC, wjoe wrote:I usually either specify the target as a dependency in meson and it just works, or I install the library and provide a pkconfig file. I'm only using dub because of vibe and I hope it would just work ;)2 issues though. - It doesn't build the library automatically, andYou'll have to invoke dub once for each config. Just slap both commands in a script.- Linking fails because error: ld: cannot find -llib<name> Built it manually via dub --config=lib and it lives inside the lib directory. Then added lflags "-Llib" to the "app" configuration but that didn't help. ld still can't find the file. Then I passed the absolute path and ld still complains. Any ideas as to why ?It's just a matter of getting the configuration right and making the linker happy. I don't think I've ever linked with anything other than system libraries on Linux, so I really don't know what it expects when linking with a custom shared library outside of the system path.Make sure that your library foo.so is named `libfoo.so`, when you pass the lib path along in dflags via -L, then make sure to change `libs "lib/foo"` to `libs "foo"`.This did the trick.The initial failure may be because of the path in the library name. I remember reading somewhere long ago that if you're passing a path in the library name (instead of using the -L flag), then you have to specify the full file name, e.g. lib/libfoo.so. I don't know if dub will pass that along correctly though. Whatever the case, trying adding -v to your dub command line so you can see exactly what's dub is calling the compiler with. That may give you a hint.It links correctly now, thanks a lot :) The only issue left is that I need to build the library manually.
Sep 18 2020
On 9/18/20 7:38 AM, wjoe wrote:Something like this: configuration "lib" { targetType "dynamicLibrary" sourceDir "source/lib/" } configuration "app" { targetType "executable" sourceFiles "source/app.d" linkWith "lib" } I found subConfiguration in the docs but that seems to be related to external dependencies. app.d merely provides a CLI to the library as well as an option to run as a server. I don't want to have the overhead of an entire git repo and such for something that is a single file and also closely related to the library.There are other options. for instance dub (the project) has a library and an application. the config looks like this: configuration "application" { targetType "executable" mainSourceFile "source/app.d" libs "curl" versions "DubUseCurl" "DubApplication" } configuration "library" { targetType "library" excludedSourceFiles "source/app.d" copyFiles "bin/libcurl.dll" "bin/libeay32.dll" "bin/ssleay32.dll" platform="windows" versions "DubUseCurl" } You can also build a subproject in the same repository. In that case, you would probably want the app to be the main project, and you then depend on the library project via "foo:lib" -Steve
Sep 18 2020
On Friday, 18 September 2020 at 14:15:27 UTC, Steven Schveighoffer wrote:On 9/18/20 7:38 AM, wjoe wrote:A subproject. Interesting. this sounds like what I want to do.[...]There are other options. for instance dub (the project) has a library and an application. the config looks like this: configuration "application" { targetType "executable" mainSourceFile "source/app.d" libs "curl" versions "DubUseCurl" "DubApplication" } configuration "library" { targetType "library" excludedSourceFiles "source/app.d" copyFiles "bin/libcurl.dll" "bin/libeay32.dll" "bin/ssleay32.dll" platform="windows" versions "DubUseCurl" } You can also build a subproject in the same repository. In that case, you would probably want the app to be the main project, and you then depend on the library project via "foo:lib" -Steve
Sep 18 2020