Dub packages: Best practices for windows support

[Mike Parker via Digitalmars-d-learn]

On Friday, 29 January 2016 at 19:46:40 UTC, Johannes Pfau wrote:

> 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.

Now you know my motivation for creating Derelict.


> 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.

IMO, no to both of these (for now). Including all of these 
dependencies is going to mean that all of your users, no matter 
the platform, will pull the down with every new version of gtkd.  
I recommend you provide all of the precompiled DLLs and import 
libraries as a separate download and let the user do the 
configuration needed to get it to link. Most Windows developers 
are used to it. You can provide instructions for those who aren't.

Hopefully one day dub will have the ability to pull down library 
dependencies on demand, or based on the current platform and 
architecture by default, then this problem goes away.

> * 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....

There's an issue for this at [1]. Until support for -m32mscoff is 
baked in, distributing any libraries with a dub project will be 
problematic.