The answer is a not-particularly-helpful "it depends." Which library are you interested in as a starting point? Not everything will be easy to build on Windows, there are often posix/unix assumptions in the code or build system. Usually the easiest way to get started is by installing MSYS2 https://msys2.github.io/ and trying to follow the normal ./configure; make build instructions for a library, but coming up with an end result that will be usable with Julia can be more subtle than that. The steps and challenges are a little bit different each time you try to add Windows compatibility to a new package, but after a few times it gets easier to estimate ahead of time how difficult a particular library will be.
On Wednesday, October 21, 2015 at 9:12:56 AM UTC-7, Joel wrote: > > Thank you Tony for your answer. I have just recently got into Python > and building/compiling with MinGW-w32 and CMake (a lot of the terminology > still goes over my head). > > Great talk! One main question from it; using Windows, is it possible to > download a package from GitHub (which currently does not support Windows) > and compile it using MinGW (creating a windows .dll file)? If not, could > you point me in the right direction as to where I can read more about how > to go ahead? > > 2015-10-20 14:15 GMT+01:00 Tony Kelman <[email protected] <javascript:>>: > >> I don't know the Java ecosystem all that well, so I couldn't tell you how >> many developers and contributors to, say, popular Apache projects do most >> of their development on Windows. If you need things like high-performance >> linear algebra you often need to go through JNI and deal with interfacing >> native and JVM code. >> >> Conda.jl should be quite useful for Python dependencies via PyCall, and >> maybe even R packages now too. But many of the C libraries provided there >> for Windows are built to work with Python, meaning using the same compiler >> that CPython was built with on Windows - Visual Studio. Visual Studio has >> lots of problems with scientific software, we have very experimental hacky >> support for compiling the core parts of Julia (LLVM, libuv, libjulia, etc) >> using MSVC but it's not exactly native and far from passing tests or a >> first-class solution. >> >> I also haven't seen many success stories of people from outside of the >> Python community using Conda as a build platform for scientific libraries >> in a way that would be usable and compatible with Julia. I personally >> prefer WinRPM since it has a comparable selection of existing libraries >> available at https://build.opensuse.org/project/show/windows:mingw:win64, >> and I've found it entirely doable to add new libraries there. You have an >> added complication of cross-compiling, but an advantage there is package >> developers never have to use Windows themselves if they don't want to. >> Having a fully automated system to build and distribute binaries is a great >> advantage, and as far as I'm aware anaconda.org does not provide >> automated Windows buildbots on their open source plan. >> >> >> On Tuesday, October 20, 2015 at 6:01:03 AM UTC-7, Páll Haraldsson wrote: >>> >>> On Saturday, October 17, 2015 at 3:29:32 AM UTC, Tony Kelman wrote: >>>> >>>> Why many packages don't support Windows? It's par for the course in >>>> open-source development, unfortunately. I gave a talk on this at JuliaCon >>>> in June where I discussed some of the challenges in making things work on >>>> Windows and how to go about fixing them, see >>>> https://www.youtube.com/watch?v=mbG-rqDCNqs - if you find packages you >>>> use that aren't currently testing on Windows but could be, I encourage you >>>> to submit pull requests adding appveyor.yml files and suggesting the >>>> authors enable Windows CI testing. >>>> >>>> Julia makes it easy to wrap C and Fortran libraries so people do >>>> exactly that quite often, >>>> >>> >>> You mean e.g. with Python. >>> >>> I can think of one exception (or not?): Java. >>> >>> At least in the beginning, that was one of it's point: >>> "write-once-run-anywhere" WORA (that assumed JVMs in web browsers..). >>> Strictly speaking, you can go out of the JVM, with JNI and have all the >>> cross-platform issues.. >>> >>> I understand WORA didn't quite work as intended, but aren't most Java >>> projects self-contained, only using Java code (or languages that compile >>> to) and Java's frameworks? >>> >>> Is it possible to replicate their (relative) success? If you use only >>> Julia code, you are portable already and codes just work.. >>> >>> >>> >>>> but building most of those C and Fortran libraries on Windows is >>>> nontrivial. Witness Anaconda, which exists to make binary installation of >>>> libraries in the Python ecosystem possible so you don't need a compiler on >>>> the user's machine at install time. In Julia we tend to focus on >>>> individual >>>> platform-specific tools, like WinRPM.jl for a large number of packages on >>>> Windows and Homebrew.jl on Mac. >>>> >>> >>> For non-Julia code, is Conda.jl the solution? >>> >>> >>>> >>>> >>>> On Friday, October 16, 2015 at 3:56:44 PM UTC-7, Joel wrote: >>>>> >>>>> Thanks for the information; food for thought. >>>>> >>>>> Out of curiosity, do you know why this is the case, by the way? >>>>> >>>>> Den fredag 16 oktober 2015 kl. 21:00:12 UTC+1 skrev Tony Kelman: >>>>>> >>>>>> Quite a few Julia packages are written in a way that assumes you're >>>>>> on Linux or Mac with build tools installed. Not all, and we're gradually >>>>>> fixing cases where packages can be made more portable. Best thing to do >>>>>> for >>>>>> now would be to submit a pull request adding a note to the readme that >>>>>> the >>>>>> package does not currently work on Windows, to save future users a bit >>>>>> of >>>>>> confusion. >>>>> >>>>> >
