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.

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/"],
	}]

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"
}

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 ?

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.

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

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.

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.