Looking at the original example of the Cpp.jl package, it appears to only be needing to call `make` at Pkg.build time in order to compile a demo test library. It should be pretty easy to modify it so it would fail gracefully with a warning rather than an error.
On Wednesday, October 21, 2015 at 10:12:09 AM UTC-7, Tony Kelman wrote: > > 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 <to...@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. >>>>>> >>>>>> >>
