> I'm worried about the legality of downloading binaries for users, since the packages involved, GMP/MPIR, MPFR and FLINT are (L)GPL.
Quite a few packages rely on (L)GPL code. The GPL is a long confusing document, and limits commercial application of some code, that's for sure, but to the best of my (IANAL) understanding it's not too onerous to comply with for open-source projects. Mostly including the license in the documentation and being careful about bundling/derived works. The spec files on the build service have to clearly state the license, plenty of libraries there are GPL and/or have GPL dependencies. > I see now that Julia adds things to the system PATH, which is why it is picking up things in the GitBash bundled in Julia. If I can figure out how to get PATH back to its original state temporarily, I think I can get the build to succeed (supposing the user has MSYS2 and Mingw64 correctly installed -- not easy, admittedly). You can modify ENV["PATH"] as you like, but I recommend against this approach. Compare the relative difficulty of building Julia from source to downloading and using the binary installer. On a slightly smaller scale, having the package rely on MSYS2 and MinGW vs just downloading binaries will lead to a similar usability comparison for your package. On Linux there's much more variety in compiler and library versions so the best way to download binaries is going through the system package manager, but if your library isn't available in the package manager then building from source is easy because compilers are really easy to install. On Mac it's a little more annoying to install compilers, so a decent number of packages use Homebrew.jl to distribute binaries. (Just have to set up a short "formula" file with instructions on how to build, and bug Elliot, @staticfloat on github, to build binaries for you). > I agree binary distribution is the normal method on Windows. But I've already been forced to go through one FSF "license compliance review" because a GNU project reported us for being in breach of the license. I'm not doing it again. > > If there is a way to do things in strict accordance with the LGPL and GPL I can go down that route. In that case, you can see the invocations here: I can imagine that experience would give you pause here. If you can link directly to the same version of GMP and MPFR as Julia is using (they are currently required dependencies, so this should be fairly safe - just have to figure out the best way to do it that would also work if someone is using their system's version of GMP and/or MPFR), then you don't need to worry about distributing anything except Flint itself. Would GMP be a drop-in replacement for MPIR for you? If we use WinRPM, I believe it would automatically detect GMP and MPFR (both are already available there) as linked DLL's and automatically download them, we just have to declare the dependency in the spec file and make sure configure picks them up or is told explicitly where they are located. They would be in a standard predictable location on the cross-compiling build machine. > https://github.com/wbhart/Nemo/blob/master/deps/build.jl > > Is that sufficient? I can see from that script how you're configuring, yes. Downloading and building your own copy of MPIR and MPFR seems slightly redundant and possibly problematic to load them from within the same process as Julia's copies of GMP and MPFR. > I should mention that there are some complications. Flint needs to be built in situ because it needs a large .txt file at runtime which contains data it uses (Conway polynomials). The only way to tell flint where it will be is through the build system, and the only way to know where it will be is to actually build flint. Can that text file be included along with the binary? > Moreover, the system linker cannot find the dependencies MPIR and MPFR of flint unless the -rpath is set by flint during build. And again, the only way -rpath can be set is if flint knows where it is being built. You can't just provide a full -L path? A few minor notes, standard convention for Julia packages is to name the Git repository include the ".jl" extension in its name. This helps visually identify Julia package repositories easily, and is nice to keep consistent. You're also frequently doing "if on_windows", there's a pre-defined macro for that: @windows_only, or the opposite @unix_only. -Tony
