On Sep 26, 3:39 pm, mabshoff <[EMAIL PROTECTED]> wrote:
> 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.
> 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? 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?
> 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. Compiling Sage from source is a huge barrier to
entry. But no binary Linux distribution can distribute the Sage
dependencies unless they do proper library versioning.
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.
> 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
-Tim Abbott
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
