Cheers, you make me feel welcome! I really appreciate your help! I have just tried it briefly, but ran into a few bumps in the road which I will try to wrap my head around (I want to give it a proper try before I come asking for help). I will get back to you, whether I succeeded or not.
2015-10-25 15:40 GMT+00:00 Tony Kelman <t...@kelman.net>: > Yes, that's about right, and don't worry about asking questions. We all > had to learn this stuff somehow. The Makefile in question for Cpp.jl is > here https://github.com/timholy/Cpp.jl/blob/master/deps/Makefile, which > is relatively simple. It assumes the presence of a compiler, by default set > to CC=gcc. > > When you first add a package, if there is a file deps/build.jl present, > then the package gets "built" by executing that script. For Cpp.jl, that > script is just run(`make`). If you want to manually trigger running the > script again, the Pkg.build function is a shorthand for doing that. > > > On Sunday, October 25, 2015 at 7:38:35 AM UTC-7, Joel wrote: >> >> Thank you again, Tony. >> >> The packages I am interested in are for wrapping c++ code, so Cpp or Cxx >> <https://github.com/Keno/Cxx.jl>. >> >> I am sorry for being slow... but compiling/building libraries is new to >> me. "Calling 'make' at Pkg.build time", is that something along the lines >> of what is described here >> <https://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html> (chapter >> 2)? Or I missed the ball? >> >> 2015-10-21 23:37 GMT+01:00 Tony Kelman <to...@kelman.net>: >> >>> 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. >>>>>>>>> >>>>>>>>> >>>>> >>
