Re: Dub packages: Best practices for windows support
On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote: 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. +1, make a Derelict-style binding and never deal with import library ever again.
Re: Dub packages: Best practices for windows support
Am Sat, 30 Jan 2016 01:17:13 + schrieb Mike Parker : > 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. Thanks for the detailed answer. Thinking about this some more, copying the DLLs automatically is really a bad idea. The cairo dll depends on Freetype, so I'd have to ship a Freetype dll as well. But cairoD depends on DerelictFT and if DerelictFT then decided to also install DLLs automatically anything could happen. So even in this simple case installing DLLs for the user is not a good idea.
Re: Dub packages: Best practices for windows support
On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote: 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. I should say "precompiled library dependencies".
Re: Dub packages: Best practices for windows support
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.
Re: Dub packages: Best practices for windows support
On Saturday, 30 January 2016 at 01:17:13 UTC, Mike Parker wrote: 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. [1] https://github.com/D-Programming-Language/dub/issues/628
Re: Dub packages: Best practices for windows support
Am Fri, 29 Jan 2016 20:46:40 +0100 schrieb Johannes Pfau : > 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 Should have mentioned DFLAGS is an environment in that example, e.g using dub like this: DFLAGS="-m32mscoff" dub run DFLAGS="-m32mscoff" dub test
Dub packages: Best practices for windows support
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