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 <t...@kelman.net>: > 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. >>>> >>>>
