> Of course you can pass an explicit directory to flint's configure to tell
it where to put this text file. Perhaps there is some canonical place.
Julia has settled on some good default choices for where to put packages by
now, the problem is users are free to override the default locations and
can have good reasons for wanting to do so.
> The Free Software Foundation explicitly says that "bindings" from a
programming language interpreter, not just linking, constitute a derived
work and therefore the combination becomes GPL'd. They are very explicit
about this on their website.
>
> I also had someone write to me the other day and refuse to access the
source code via Github because they "refused to indemnify Github against
all damages". It's not clear if I am required under the GPL to send them
the source code some other way...
Oh dear. Well what I've been doing when building binaries is including the
Readme and the License files as part of the packaging, so those will always
get installed along with the dll's.
> We also need to either include the full source code of flint with the
binary, or a written offer to supply it upon request. Here the FSF claims a
link to a website is not really good enough because the URL might change.
As a result of this, I am personally very reluctant to not just supply the
source code for flint. I also want people to have the git repository
automatically so they can contribute to it if they want.
Okay. It's not the end of the world to checkout the source code even when
downloading a binary. Though keep in mind that for Julia 0.4, the plan is
to transition Julia's package manager from relying on shelling out to
command-line git to using ccall bindings to libgit2, so it won't
necessarily be a safe assumption to make that you can always shell out to
git. That's still a ways out though, and you can always put a try-catch
around the checkout since it's not an absolute requirement.
> We're also not yet fully in compliance with the GPL. Because it is an
interpreted environment GPL v2 (which flint uses) requires a notice to be
printed when Nemo starts up saying that the program comes with no warranty.
I'll have to add that, if I can figure out how.
That should be pretty easy with a println in your Nemo.jl module file,
should come up any time anyone calls "using Nemo". You can also write a
function called __init__() that gets called on package startup. Not sure
if/where in the docs that's listed.
> Unfortunately it doesn't even work on my machine. It seems ok for some
calls into the dll, but as soon as I try to say print something using a
function in the MPIR dll it segfaults. I suppose it must be linked against
subtly different Microsoft dll's than Julia and some kind of conflict
results.
Or maybe different GCC dll's. Exactly which version of MinGW-w64 are you
using? Might not be compatible with what was used to build Julia. Or there
could be some issue due to having gmp and mpir both loaded within the same
process? We've seen sort-of-similar issues with blas and lapack and various
packages, though not so much on Windows.
> The problem must be what libtool is doing on mingw64. Make install
doesn't even copy the generated dll across to the install directory, so you
have to do this manually.
Hm, yeah, libtool can be very picky, especially when it comes to dll's. I
think I've used the "subtle and quick to anger" quote on this list before
when talking about libtool... I've found configuring
with lt_cv_deplibs_check_method=pass_all can sometimes help.
> I also can't build flint against the Julia mpir and mpfr since Julia
doesn't seem to distribute the gmp.h and mpfr.h files, and flint requires
these when building.
Oh, right, damn. Sorry I forgot about that! That is an issue, maybe we
should open a separate discussion on that general topic. It has come up
before that various packages would like to link against the same libraries
as Julia (in the Blas and Lapack cases we're building with an incompatible
ABI which makes this actually not a good idea in most cases, but for GMP
and MPFR I think we're configuring them in the default way), so installing
the corresponding headers would actually be necessary.
Even though I'm not entirely sure what Nemo or Flint do or whether I would
personally have a use for them, I have some strange desire to see more
Julia packages be painless to install cross-platform and want to help here.
Let me know how the runtime configuration of the text file location goes,
then I can mock up what BinDeps would look like. It should simplify your
deps/build.jl script by automating the standard download, extract,
configure, make steps. There are also some Julia idioms like
joinpath("a","b") that would be cleaner than what you're doing now with if
statements to switch between forward slashes and backslashes, and things
like
cd(newdir) do
...
end
that work in a nicer way including returning to the old directory even on
failure.
