Thanks for checking that. I'll try to work on those things this weekend. The amount of time I'll have to work on Nemo for the next two months will be smallish, but not completely zero. So we'll get it there eventually.
Bill. On 23 September 2014 21:16, Tony Kelman <[email protected]> wrote: > 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. >>> >>> >>>
