dub
dub copied to clipboard
dlang
Windows regression: dynamicLibrary targets wrongly copy all static .lib files they depend on
As per title. In our case at work, standalone dynamicLibrary targets linking all dub deps statically now get dozens of static .lib files copied to their output directory. This didn't happen with dub v1.28 but does for recent dub master.
This one is almost certainly on me. The problem is import libraries have the same extension as static libraries and it'll be copying them all by extension a bit too eagerly.
On Fri, Aug 12, 2022, 13:07 Martin Kinkelin @.***> wrote:
As per title. In our case at work, standalone dynamicLibrary targets linking all dub deps statically now get dozens of static .lib files copied to their output directory. This didn't happen with dub v1.28 but does for recent dub master.
— Reply to this email directly, view it on GitHub https://github.com/dlang/dub/issues/2377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHSL46DHKHHYZANKEVFUQ3VYWPT3ANCNFSM56KBSNVQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I have a hunch that this should not be a regression.
If you convert it to executable, using the older dub, does it still exhibit this behavior?
On Fri, Aug 12, 2022, 18:39 rikki cattermole @.***> wrote:
This one is almost certainly on me. The problem is import libraries have the same extension as static libraries and it'll be copying them all by extension a bit too eagerly.
On Fri, Aug 12, 2022, 13:07 Martin Kinkelin @.***> wrote:
As per title. In our case at work, standalone dynamicLibrary targets linking all dub deps statically now get dozens of static .lib files copied to their output directory. This didn't happen with dub v1.28 but does for recent dub master.
— Reply to this email directly, view it on GitHub https://github.com/dlang/dub/issues/2377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHSL46DHKHHYZANKEVFUQ3VYWPT3ANCNFSM56KBSNVQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Yep, this was almost certainly introduced by #2259.
If you convert it to executable, using the older dub, does it still exhibit this behavior?
I assume you meant the newer dub - yes, loads of useless files ending up in the output dir too now. And an import lib for the executable (it has a few exports). Edit: And no .lib files with dub v1.28.
Copying the import .lib and .exp files is fine - but IMO only for the dynamicLibrary target itself. So not for an executable target even if it has exports, and definitely no .lib/exp files from dependencies - regardless of whether they are static libs or dynamic libs (edit: but the .{dll,so,dylib,pdb,dSYM} files from dynamicLibrary dependencies are desirable).
Yep, this was almost certainly introduced by #2259.
If you convert it to executable, using the older dub, does it still exhibit this behavior?
I assume you meant the newer dub - yes, loads of useless files ending up in the output dir too now. And an import lib for the executable (it has a few exports).
No, I did mean the older dub.
For executables that should be an easy change. Just move a couple of the extension handling into its own dynamic library check.
https://github.com/dlang/dub/blob/master/source/dub/generators/build.d#L423
However, as for dynamic libraries as dependencies, this is a capability that I do want. This makes picking and choosing for distributing (say frameworks) as binaries much easier. The alternative is to go looking into build directories or do it step by step which are both more work than what should be required for common outputs.
My changes should not have affected static libraries.
Right now things are consistent, but yeah I can see why a large project like that might have a bit of a problem. We may want to split binary copying into "default" and "full" directives for target directory support.
However, as for dynamic libraries as dependencies, this is a capability that I do want. This makes picking and choosing for distributing (say frameworks) as binaries much easier. The alternative is to go looking into build directories or do it step by step which are both more work than what should be required for common outputs.
I disagree. Building a dub project is just that - a single project. The output dir should contain what's required to deploy/redistribute that project. If that's a dynamicLibrary, copying the import .lib makes perfect sense for redistribution.
But IMO that clearly doesn't apply to its dependencies - the dynamic library ('myDll') is 'fully' linked, dependees don't need any import libs etc. from the lib's dependencies. If the root package depends on a dynamicLib ('mySharedChild') which myDll also depends on, no problem, dub should take care of linking the mySharedChild import lib from the dub intermediate output dir, as if it was a static lib.
For 'frameworks', a set of DLLs, I'd say the solution is to merge the output dirs of all libraries, and redistribute that.
For 'frameworks', a set of DLLs, I'd say the solution is to merge the output dirs of all libraries, and redistribute that.
I really don't want to have to do this. Dub is fully capable of doing this itself, there is no reason for it to be done by a human.
Ultimately we are wanting two separate behaviors, a default that only offers what is required to run&debug, and a full set of binaries.
I think trying to represent a framework, i.e., multiple projects, as a single dub project is a) not intended, and b) extremely exotic.
It's not multiple projects as a single one, the root package only acts as a trigger for the dependencies to be built and aggregated.
Of course, in saying all this, no one has figured out how to resolve any of the issues associated with distribution/install just yet. We still have the problem with RPATH for *nix for instance.
It's not multiple projects as a single one, the root package only acts as a trigger for the dependencies to be built and aggregated.
That's a rather common case I think, and handled just fine when using dub for the dependees too. It's only when wanting to distribute a set of DLLs for 'dub-external' linking that one needs the import libs for all of these DLLs. For this presumably exotic use case, I think it's fine to require merging the individual output dirs manually, or e.g. specifying the same output dir for the libs defined as dub subpackages of the 'framework' package.
specifying the same output dir for the libs defined as dub subpackages of the 'framework' package.
Ah you have misunderstood me, they are not sub packages, but actual packages in separate repos that may not have any relationship to the whole beyond being a dependency.
I just meant that as an option if the framework is structured as subpackages, which is probably how I would do it.
I understand a framework as a specific set of libraries, not a set of libraries and all its dependencies. E.g., a framework library might have a mySuperMalloc.dll dependency as an implementation detail, and including an import lib for that abstracted-away dependency might not be desirable.
Oh wait - templates. I thought we wouldn't have to link transitive dependencies of dynamicLibrary deps, but we do of course. Then a dev package of a framework really must include every single import lib.