www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - dub: Is it possible to have a library target and depend on it in the

reply wjoe <invalid example.com> writes:
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
next sibling parent Danny Arends <Danny.Arends gmail.com> writes:
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
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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
parent reply wjoe <invalid example.com> writes:
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:
 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" }
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 ?
Sep 18 2020
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 18 September 2020 at 12:28:30 UTC, wjoe wrote:

 2 issues though.
 - It doesn't build the library automatically, and
You'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
parent wjoe <invalid example.com> writes:
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:

 2 issues though.
 - It doesn't build the library automatically, and
You'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.
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 ;)
 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
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
parent wjoe <invalid example.com> writes:
On Friday, 18 September 2020 at 14:15:27 UTC, Steven 
Schveighoffer wrote:
 On 9/18/20 7:38 AM, wjoe wrote:
 [...]
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
A subproject. Interesting. this sounds like what I want to do.
Sep 18 2020