On second thought ECOS.jl is a simpler example: https://github.com/JuliaOpt/ECOS.jl/blob/master/deps/build.jl
Or MbedTLS.jl, very similar but with multiple libraries: https://github.com/JuliaWeb/MbedTLS.jl/blob/master/deps/build.jl On Monday, September 14, 2015 at 5:51:33 PM UTC-7, Tony Kelman wrote: > > All Julia needs is dll's. Best to refer to them via absolute paths in > ccall. See how SCS.jl handles these for a simple example: > https://github.com/JuliaOpt/SCS.jl/blob/master/deps/build.jl > > Requiring Windows users of your package to have an MSYS environment and > MinGW-w64 toolchain installed on their computers is asking for trouble and > not at all recommended. I don't see why any library that you could build on > Windows with MinGW-w64 couldn't build in cross-compilation from the > opensuse build service - generally it's a deficiency in that library's > build system that should be fixable. Cross-compilation is something that > autotools is very good at, CMake is decent at if you know what you're > doing. Rolling your own non-standard build system is asking for trouble, > you can see places where Julia's own makefiles have gone to extra lengths > involving XC_HOST to make this possible. > > If you have a working build setup from a local Windows machine that can > produce dll's, most of what you need to do is upload those dll's somewhere > (bintray works fairly well) then set up the BinDeps scripts to download and > determine the install-time paths. > > > On Monday, September 14, 2015 at 5:23:12 PM UTC-7, Bill Hart wrote: >> >> Hi, >> >> I'm currently up to working on building the dependencies for our Nemo >> computer algebra package for Julia: >> >> https://github.com/wbhart/Nemo.jl >> >> We have dependencies on the following C libraries: >> >> libpari (Pari/GP) >> Antic (https://github.com/wbhart/Antic) >> Flint (https://github.com/wbhart/flint2) >> mpfr >= 3.1.2 >> gmp >= 5.1 >> >> Whatever logic I had already coded up in our build.jl to build these on >> Windows 64 and use them from within Julia no longer works. We always knew >> that there were going to be changes in the way things worked, so this is >> not unexpected. >> >> So I thought I would take a look at the OpenSUSE build service. But >> flint, pari and antic are not available on there. (I found the WebRPM >> package for Julia and have been using that.) >> >> It looks like someone has tried to build flint on there, but their system >> doesn't cope with the flint build system (or vice versa if you prefer). >> >> Pari only builds on Windows 64 with some coaxing (I have succeeded in >> doing that). It certainly won't build with OpenSUSE. >> >> So this means I have to build these binaries myself perhaps and just >> download them from somewhere on the web, which I'm happy to do. >> >> So I tried building binaries in both msys2 and mingw64. After much work I >> cannot figure out where Julia expects to find the binaries. I've tried >> setting PATH and Libdl.LD_LOAD_PATH appropriately. I've tried static and >> dynamic libraries, but under no circumstances can I get Julia to find the >> libraries. It just says the "module is not found" when trying to ccall them. >> >> Moreover, OpenSUSE doesn't provide a "make" package, as far as I can see. >> And make is not available from the GitBash shell in Julia on Windows 64. So >> even building the software from within Julia currently seems impossible. >> >> I also had problems with the gcc not wanting to build 64 bit binaries. >> >> Given that OpenSUSE appears out of the question for us on Windows 64. can >> anyone shed any light on how to get Julia compatible libraries built >> (msys2, mingw64??) and what the current best practice is for ccall'ing >> those binaries (how to set the linker path?). >> >> Note that flint and pari both have custom configure arguments that must >> be set and neither flint nor pari uses autotools, though both roughly >> emulate an autotools build with some extra bells and whistles. >> >> Any help would be very much appreciated. We have everything working >> beautifully on Linux, but one of the big selling points for us is that the >> entire Julia stack works natively on Windows. This is an especially big >> thing for us given that IJulia also works on Windows (most computer algebra >> systems do not work on Windows). >> >> Julia is working beautifully for us and we have 40-50,000 lines of Julia >> code locally for our computer algebra package (Nemo + Hecke). But getting >> it working on Windows just seems to be outside of my current skill set. >> >> One other minor question: because we currently need to build the >> libraries ourselves, we have to (or would like to) run configure and make, >> etc., from the shell in Julia. This means directories have to be converted >> from the C:\\abc\\def style to /c/abc/def/ style. Is there a Julia function >> for doing this, or a best practice? >> >> Bill. >> >> >>
