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 <javascript:>>: > >> 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. >>>>>>>> >>>>>>>> >>>> >
