On 06/03/2023 3:49 PM, ryuukk_ wrote:
> On Monday, 6 March 2023 at 01:57:21 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> On 06/03/2023 2:52 PM, ryuukk_ wrote:
>>> Are you saying dub doesn't build a static dcd.lib?
>>
>> It did, but it doesn't contain any of the dependencies.
>>
>>> What to do to make it so i get a static dcd.lib file that contains all the code it needs?
>>
>> $ dub build --combined
>>
>> That may work. No guarantees. Dub isn't setup for distribution like this.
> 
> combined didn't work, i still get a bunch of unresolved symbols (although less long):
> 
> https://gist.github.com/ryuukk/d59eb89979f1666139ffe0ac95307f20

I've got it to work via:

$ cd DCD
$ dub build --build-mode=allAtOnce --combined
$ cd ..
$ ldc2 app.d DCD/dcd.lib

```d
void main(string[] args)
{
    init_dcd();
}

extern(C) void init_dcd() {}
```

ldc2 on Windows.

DCD/dcd.lib should be about 23mb.

I did have to hunt some files down, it seems some build commands in DCD isn't setup for this (almost certainly not using the environment variables that dub offers to handle this situation).

On 3/5/23 9:09 PM, ryuukk_ wrote:
> On Monday, 6 March 2023 at 02:00:16 UTC, Mike Parker wrote:

>> This is not dub's fault. When building a shared library, there's a link step, so any external dependencies are linked into the shared library just as they are with an executable. There is no link step with a static library. That means when you build your executable, you need to also link the static library's dependencies along with it.
>>
>> Most of the symbols in your list appear to come from the packages listed in the dependencies section of DCD's dub.json:
>>
>> https://github.com/dlang-community/DCD/blob/master/dub.json
>>
>> So if you want to do this manually, with DCD as a static library, then you also need to build all of those dependencies and link them with your executable.
> 

Well, you can create a library that contains all the static libraries, you just can't use dub to do it for you automatically, or even manually (dub ignores `.a` files when specified as source files).

> dub should build a static library for the project i build, that includes each library it uses that are referenced as "library" since the default is "staticLibrary" according to rikki
> 

Dub expects to have dub-built artifacts available to link. This problem only occurs if you are building outside of dub, without proper dependency management.

Dub indeed does not play nice with exporting artifacts for other build systems. It's something that should be addressed.

Keep in mind though, that you still need to specify any shared library dependencies, since static libs cannot contain shared libraries or automatic references to them.

-Steve

On Monday, 6 March 2023 at 02:09:23 UTC, ryuukk_ wrote:

>
>
> dub should build a static library for the project i build, that includes each library it uses that are referenced as "library" since the default is "staticLibrary" according to rikki

What you're asking for is a different use case. `staticLibrary` is for compiling a specific dub package as a static library. It does not imply that all of that package's dependencies should also be compiled into a single static library. Nor should it.

You're asking for a package and its dependencies to be bundled for use outside of the dub ecosystem as a single static library. I won't say it's not a legitimate use case, it's just not one that dub currently supports, nor was it originally intended to (I wouldn't expect it to be a common one either, but then again common expectations are always changing).

As a potential dub enhancement, e.g., `staticLibraryBundle`, I do agree it's worth exploring. I don't believe you can expect every package to "just work" in that environment. As Steve mentioned, there will always be link-time dependencies to any shared libraries on which those bundled libraries depend. And some packages may be set up in a way that causes issues, as Rikki noted when he said he had to make some tweaks on his successful build.

But for the time being, dealing with static libraries in D is just the same as dealing with them in the C and C++ world. They always have been a PITA to deal with, and that's why the trend in recent years has been to move away from them. Build tools like dub hide them from you when used as intended. It's when you mix build systems that you run into trouble.

Still, I suggest you send an email to social@dlang.org as part of the Gripes and Wishes campaign so that this gets added into the dataset. Anything that enhances dub's usability should be looked at.

On Monday, 6 March 2023 at 05:59:09 UTC, Mike Parker wrote:
> On Monday, 6 March 2023 at 02:09:23 UTC, ryuukk_ wrote:
>
>>
>>
>> dub should build a static library for the project i build, that includes each library it uses that are referenced as "library" since the default is "staticLibrary" according to rikki
>
> What you're asking for is a different use case. `staticLibrary` is for compiling a specific dub package as a static library. It does not imply that all of that package's dependencies should also be compiled into a single static library. Nor should it.
>
> You're asking for a package and its dependencies to be bundled for use outside of the dub ecosystem as a single static library. I won't say it's not a legitimate use case, it's just not one that dub currently supports, nor was it originally intended to (I wouldn't expect it to be a common one either, but then again common expectations are always changing).
>
> As a potential dub enhancement, e.g., `staticLibraryBundle`, I do agree it's worth exploring. I don't believe you can expect every package to "just work" in that environment. As Steve mentioned, there will always be link-time dependencies to any shared libraries on which those bundled libraries depend. And some packages may be set up in a way that causes issues, as Rikki noted when he said he had to make some tweaks on his successful build.
>
> But for the time being, dealing with static libraries in D is just the same as dealing with them in the C and C++ world. They always have been a PITA to deal with, and that's why the trend in recent years has been to move away from them. Build tools like dub hide them from you when used as intended. It's when you mix build systems that you run into trouble.
>
> Still, I suggest you send an email to social@dlang.org as part of the Gripes and Wishes campaign so that this gets added into the dataset. Anything that enhances dub's usability should be looked at.


Having a way to define a static library bundle is really great. It does help a lot when you create a package where it is initialized in non D code.

Right now, this is the third time I'm going to need it for my engine, for MacOS I need to manually assign my dependencies, and having only the main code as a library doesn't work for that purpose. I have done before a simple program which executes dub describe for taking the dependencies then I build the program as a staticLibrary, problem is that this requires a 2-pass build and it is not standard.