Dub packages: Best practices for windows support
Johannes Pfau via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Fri Jan 29 11:46:40 PST 2016
I want to add proper windows support to the cairoD dub package. cairoD
is a wrapper for the [cairo](http://cairographics.org/) C library. As
it can be difficult to obtain cairo DLLs on windows I want to ship
these DLLs with cairoD. It is also possible to enable or disable
additional cairo features. I want to use the DLLs from the [MSYS2
project](http://msys2.github.io/) which enable all relevant features.
Because of that, the MSYS2 cairo DLL depends on _13_ other DLLs.
On linux it would be common practice to simply have a "libs": ["foo"]
entry in the dub configuration for cairoD. This way applications using
the library won't have to manually link the C library. And everything
(dub run, dub test) will just work.
Now on windows, things are more complicated. First of all, I can't seem
to simply use "libs": ["foo"] as the linker won't find the C
import .lib file. Then apparently there's no way to add a library search
path with the MSVC linker? So I have to use the full path:
"libs": [$PACKAGE_DIR\\path\\foo]. Without $PACKAGE_DIR paths are
incorrect for applications using the library because of a dub problem.
And then I'll have to use different import libraries and paths for -m32,
-m64 and -m32mscoff.
Additionally, applications can't run without the DLLs in the same
directory as the target application executable. So dub run and dub test
won't work. As a solution it is possible to do this in the cairoD dub
configuration:
"copyFiles": ["lib\\dmc32\\*.dll"]
The path again depends on -m32 vs -m64 and -m32mscoff
All this leads to the following questions:
* Should cairoD copy the DLLs for all applications using cairoD? This
way simply adding a dependency will work. However, if users want to
use a self compiled cairo DLL with fewer dependencies there's no easy
way to disable the file copying?
* Should cairoD link in the .lib DLL import file? This might be useful
even when not copying the DLLs. But if users want to link a custom
import library that would be difficult. OTOH not copying DLLs and/or
not linking the import library will make dub.json much more
complicated for simple applications, especially if these applications
want to support -m32, -m32mscoff and -m64.
* What's the best way to support all of -m32, -m32mscoff and -m64? I've
got working import libraries and DLLs for all configurations, but how
to support this in dub.json? I think the best way would be to have
-ms32coff as a special architecture or flag for dub, but I can't seem
to find any documentation about that. -m64 can be detected by x86_64
in platforms, but how to detect -m32 vs -m32mscoff?
Alternatively I could simply let users choose the configurations
manually. But adding dflags: ["-m32mscoff"] does not build the
Derelict dependencies with the m32mscoff flag so linking will fail...
DFLAGS="-m32mscoff" doesn't work with dub test as the dub test
command ignores the DFLAGS variable. I'd have to check whether it
works for applications, but then there's still no way to use the
correct cairo import library in cairoDs dub.json....
More information about the Digitalmars-d-learn
mailing list