> 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. > 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). > 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. 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. 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 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.
