On Sep 27, 8:50 am, Tim Abbott <[EMAIL PROTECTED]> wrote: > On Sep 26, 3:39 pm, mabshoff <[EMAIL PROTECTED]> wrote:
Hi Tim, > > For example: Take the FLINT.spkg - ever since we used the patches Tim > > submitted the spkg was broken twice by either not adjusting the link > > name for libfint.so or after installing an updated version Sage would > > I think this is really the victim of Sage not using the install target > from the upstream FLINT package. Sage should not need to be > maintaining code to copy FLINT's libraries into place and install the > right symbolic links. I believe if we were to automakeify FLINT, the > install targets would do the right thing with installing symlinks > appropriately on all platforms supported by libtool. I still don't see the benefit of versioned libraries for Sage. And automakifying FLINT will only make the build process slower and more complicated. I fixed a gmp linking issue in FLINT on Cygwin trivially in 3 seconds while a similar fix with link order for LinBox when using Givaro was way more involved. > > Well, in theory: yes. But autoconf does not work on Windows and > > I guess this is referring to native Windows, as opposed to Cygwin? Or > does autoconf not work on Cygwin either? It does not work on native Windows, it mostly works in Cygwin. It can be made to use the native MS compilers via some POSIX shell, but that is prone to break, i.e. spaces in paths and so on > Sage must already have some > 30 packages that use autotools; is the worry that we're making a > native Windows port even harder by adding 10 more? Because the autotools are a 20 year old mess of incompatible versions and generally have the elegance of a car with square tires :). We don't need to push another ten software packages toward autotools and forgo the use of a saner cross-platform build system. Many of the spkgs which do not have a autohell base build system are small packages and making them autohell based will increase their build time significantly since the configure process can run for quite a while. This is even worst on Cygwin where shell scripts run dog slow. > > various spkgs do neither use autoconf or SCons. And I do not want to > > move more code to use autoconf since IMHO it plainly sucks. There are > > alternatives that work on Windows for sure, but that is likely even > > more work since few people use SCons for example. One can always have > > two build systems, i.e one for Windows and one for the rest. > > In the future, I think most people will want to get Sage via their > binary Linux distribution, rather than having to compile it from > source themselves. Nope, once the Cygwin version is out that will be the most downloaded version. Back in the day when we had a Cygwin build about 2/3rds of the downloads were Cygwin and I see no reason that will not change in the future. I wholly expect this number of Windows downloads to be even more dominant once we have a native version. > Compiling Sage from source is a huge barrier to > entry. I disagree, building Sage is trivial compared to the complexity of similar packages. It might be that some users will not use Sage when it has to be build from sources, but we have binaries, too. > But no binary Linux distribution can distribute the Sage > dependencies unless they do proper library versioning. Sure, but that is not the problem I need to solve :) > The patches for adding sonames that Francois and I wrote were indeed > not designed with Solaris and BSD's non-GNU toolchain in mind. The > right way to solve this problem is to use libtool, since that the > standard way to do portable versioning for libraries. The easiest way > to use libtool is to use automake, and I'd be willing to generate > patches to make the Sage dependencies to which I've added versioning > use automake (with the exception of Singular, which probably needs a > more incremental solution). > > I'm not convinced that Scons is an option for this; its documentation > does not suggest to me that it has a portable mechanism for specifying > the soname of a library. I have not checked into this, but PolyBoRi seems to do fine. I am still not convinced versioned libraries are a necessity for Sage itself. Just because the Debian packaging rules demand it does not make a case. It does make sense for Debian, but not for Sage IMHO. So let the Debian packagers deal with versioned libraries, I just don't see any reason to support it in Sage especially if they break ports. > > But the above problems do also cause trouble when I upgrade an spkg > > when doing merges, i.e. if I updated ntl I would hate to rebuild all > > of Sage. As is the soname of FLINT is changed *every* time the minor > > version is bumped. > > Well, if FLINT were using automake, it would be easy for them to only > change the soname when it is necessary (i.e. when an interface is > removed). The soname bumps are a nuisance for me as well, since > packages have to pass through the Debian NEW queue every time their > soname changes Yeah, this is certainly bad, but I also pretty much doubt for most of the upstream authors pay attention to sonames and preseving upward compatibility. There was a recent discussion on the mpfr mailing list where some people complained that backward compatibility was broken since the mpfr 2.3.1 test suite could no longer link against the mpfr 2.3.2 library and vice versa and as it turned out that some auxiliary function had been removed that was never intended to be used. So where you draw the line? My personal conclusion (and I know I am repeating myself) is that in Sage's situation we just should not care and not deal with versioned libraries and be done with it. Whatever upstream packagers do is orthogonal to that, but any "fix" that will introduce GNUisms will be removed from the spkg or the updated spkg will not be merged. > -Tim Abbott Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
