On 14 September 2014 06:14, Tony Kelman <t...@kelman.net> wrote: > > We tend not to use tags. But there's no problem introducing a named tag > to pin things. > > Any reason why not? Your code is on github but your releases aren't, would > be great if it was possible to track exactly which commits correspond to > exactly which numbered release version. >
We have been using branches, not tags for that. We like to only push fixes to release branches, whilst work continues in trunk, and make those minor point releases, 2.4.0, 2.4.1. 2.4.2, etc. I suppose we could tag all the releases in their branches too. > > > The way it currently works is the user will specify --prefix. This is > where libflint will be installed (in a subdirectory called lib). Obviously > a default is chosen otherwise. > > > > Flint is at first built inside its own source tree. Flint knows where to > find the file relative to this source tree. > > > > But when make install is issued, it will be moved across to --prefix. > > > > As flint is compiled, --prefix is used to generate an absolute path > where the text file will be stored, and this is baked into the library, > which then also looks in this absolute path. > > > > Of course the absolute path is computed at compile time to be some path > relative to --prefix. It is passed to the relevant parts of flint via a -D > define. > > None of this is going to work if you want the library to be usable on a > different machine than it gets compiled on. That's a pretty big restriction > to put on your users. A bit like using Gentoo - some people think it's fun > out of masochism or something, but not many. Most users would rather save > time and use binaries wherever possible (assuming the results are the same > and you don't introduce any compatibility problems - if you use an > automated build service and a package manager these are easy). > We'd like to fix the problem. We just don't know how. At some point, the library has to read from a large text file. There must be a relocatable way of doing that. 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. > > > I don't know of a way to encode a path relative to where the library is > installed. That would be very useful, if possible. But I'm not sure if it > can be done. > > I'm actually not sure how fopen() with relative paths would work inside > library code - it might depend on the current working directory of the > calling process, which is also something you probably shouldn't be imposing > restrictions on. This path is going to need to be runtime configurable, I > don't see any other way around it. > That should be possible. I'll add a function to set it at runtime. > Unless you want to generate the file in such a way that it becomes valid C > syntax assigning into one string per line or an array of integers per line, > then use it during compilation as a .c or .h file. > > > Since git is installed with Julia, I'd like to git clone flint as part > of the install process, so that the user always has the source code of > flint (and the license, etc). > > This isn't necessary. The flint source code is on github, it's pretty > simple to document that and point people to the right place if they want to > look at it. Keep in mind that not all Julia package users are going to > understand or care about the source code of a C library. The Julia package > existing and providing access to some of the functionality is enough for > many users. > > > Flint is GPL, not LGPL. There is no linking exemption for flint. On the > other hand, the FSF seems to be pretty isolated in its position that > dynamic linking to a library results in a derived work. Fortunately there > is almost no FSF code in flint and it is all LGPL'd. No one else is going > to care. > > I don't know if we've gotten a clear legal intepretation of exactly where > Julia's ccall falls with respect to licensing. I don't think it's exactly > the same thing as linking. > 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... 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. 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. > If your non-GPL Julia package depends on a GPL library and is going to > automatically download that GPL library (either from source or from a > binary) as part of its installation, then you should clearly document that > fact. There are companies that forbid their employees from using or looking > at GPL code. > > I know. We will do this too. We tried to get rid of the GPL in flint recently, hoping we might even make it BSD licensed or compatible. We spent some time contacting copyright holders. Some umm'd and ahh'd and never gave us a response. Others we have not been able to track down at all. At least two have fairly famously "disappeared" and not been contactable from anyone in the Open Source community. The contributions of one are probably not legally significant. The other previously authorised us to use the LGPL. But at this point, unfortunately we are stuck with the GPL in flint. > > I think I will get things going temporarily on Windows by modifying PATH > first. Then I will promise a binary distribution method to come, which we > can work on. > > Alright. Just to warn you again, plenty of MinGW users refuse to add MinGW > permanently to PATH, due to the compatibility issues that introduces. More > often than not you need to work with several different subtly incompatible > toolchains, and putting any of those on PATH permanently is > counter-productive. So this installation method is something that you may > get to work on your machine, but it's unlikely to work many other places. > > > 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. The dependency walker does show some missing dll's, but they are all obscure Microsoft ones. Perhaps that is normal, I don't know. I have had it working on my machine, but only if I build all the dlls myself from msys2, not from within Julia (even if I pop the Julia paths off the PATH environment variable so that it really uses msys2). I realise that binary distribution is going to be the only solution for many Windows users in the long run. I just thought I could quickly get something working for people who were prepared to uninstall old versions of msys, install msys2 and put it in their path. I have to admit to being quite personally disappointed that I haven't been able to get that to work. Bill.
