Great. Bumping the git version to a51e15e53d636e38c107e48f1d8ec34a932590ab looks like it built okay: https://build.opensuse.org/package/show/home:kelman/mingw32-flint
We'll need to adjust Nemo.jl's deps/build.jl script to use BinDeps Autotools/WinRPM providers and library_dependency's instead of just running shell commands. Will also want to use the library location caching method instead of push!'ing to DL_LOAD_PATH. On Tuesday, September 23, 2014 9:39:45 AM UTC-7, Bill Hart wrote: > > Sorry for the delay, but I have now added a function to flint which takes > the location of the CPimport.txt file (which is in the flint source tree in > the qadic directory) at runtime. > > The function is void flint_set_cpimport(char * path); where path is a full > path including filename of the (CPimport.txt) file. > > This is now committed to the flint trunk branch in my github. We should be > able to use this by calling it from Julia when initialising anything that > requires Conway polynomials. I haven't made the necessary changes to Nemo > yet, but most of Nemo works without the changes since only the finite field > functionality actually use Conway polynomials. > > This should allow us to move forward with a binary version of Nemo on > Windows, as soon as we decide a good place to install the CPimport.txt > file. I guess it could just sit in the Nemo directory and just be made part > of the Nemo git checkout. > > Bill. > > On Monday, 15 September 2014 14:45:01 UTC+2, Tony Kelman wrote: >> >> > I think this is very common. But it means that people who really want >> their code to actually compile on Windows frequently have an inferior >> system with which to do it, because all the real hackers are cross >> compiling from Linux. >> >> Or Cygwin. Part of the point is the exact same process should result in >> the same built binaries for cross-compilation from Linux or >> cross-compilation from Cygwin. Any complaint about Cygwin in terms of size >> or performance applies equally to MSYS2, and MSYS2's newness and multitude >> of build/run modes causes more trouble than it's worth in many cases. >> >> > or provide Visual Studio project files >> >> Can you blame them? Speaking of awful, impenetrable build systems that >> don't translate well to other platforms... >> >> > MPIR and GMP are *incredibly* complex projects and few people recognise >> the subtleties which simply don't arise for other types of software. >> >> I'm not familiar with writing this type of software, but plenty familiar >> with building it, and I really don't see a whole lot that goes into a >> bignum library that doesn't also happen in, say, an optimized BLAS/LAPACK >> implementation. Of course those are also notorious for having messy and >> fragile build systems. >> >> >>
