Spielwiese: library structure

[François]

Hi,

I have been looking at the spielwise branch for the last few days to see what I could contribute to the build system mainly. There are many more libraries than in the current release of singular and it is not entirely clear how they depend on each other. More to the point there are libraries and modules all over the place.

The p_Procs_Field*.so modules are shipped in $bindir and some more modules are shipped in $bindir/MOD this is not a traditional place for that kind of files. A better place would be $libdir/singular or a subfolder therein.

There are libraries in $libdir and $libdir/singular, why not put all the libraries just in $libdir? why do some need to be in a subfolder?

Cheers,

Francois

[Burcin Erocal]

Hi Francois,

most members of the Singular team were traveling to a workshop in St.
Andrews in the past few days. Finally we have internet access and time
to check emails. :)

On Wed, 22 Aug 2012 17:01:18 -0700 (PDT)
François <francoi...@canterbury.ac.nz> wrote:

> I have been looking at the spielwise branch for the last few days to
> see what I could contribute to the build system mainly. There are
> many more libraries than in the current release of singular and it is
> not entirely clear how they depend on each other.

There is a dependency diagram, mainly for our benefit, in singular.dot
at the root of the repository. Here is a png version:

http://sage.math.washington.edu/home/burcin/singular/singular_dependencies.png

> More to the point
> there are libraries and modules all over the place.
> The p_Procs_Field*.so modules are shipped in $bindir and some more
> modules are shipped in $bindir/MOD this is not a traditional place
> for that kind of files. A better place would be $libdir/singular or a
> subfolder therein. There are libraries in $libdir and
> $libdir/singular, why not put all the libraries just in $libdir? why
> do some need to be in a subfolder?

I agree that these files can be placed in a better location like
$libdir/singular. I don't know if modifying the build system is enough
to make the new scheme work. The singular executable needs to find
these based on its current location. Perhaps as a workaround you can put
the singular executable in this directory and make a symlink from
bin/Singular.


Cheers,
Burcin

[François Bissey]

Hi Burcin,

On Mon, 27 Aug 2012 17:20:36 Burcin Erocal wrote:
> Hi Francois,
>
> most members of the Singular team were traveling to a workshop in St.
> Andrews in the past few days. Finally we have internet access and time
> to check emails. :)
>
> On Wed, 22 Aug 2012 17:01:18 -0700 (PDT)
>
> François <francoi...@canterbury.ac.nz> wrote:
> > I have been looking at the spielwise branch for the last few days to
> > see what I could contribute to the build system mainly. There are
> > many more libraries than in the current release of singular and it is
> > not entirely clear how they depend on each other.
>
> There is a dependency diagram, mainly for our benefit, in singular.dot
> at the root of the repository. Here is a png version:
>
> http://sage.math.washington.edu/home/burcin/singular/singular_dependencies.p
> ng

Couldn't see that file. But good old imagemagick display .dot files. As far as I
am concerned from analysing the symbols dependencies of the various libraries
it is incomplete (from memory). As I mentioned elsewhere the libraries are
badly underlinked - the problem is that there are a few circular linking
dependencies. Of course shared objects don't have to resolve all the symbols
until run-time but it is not considered good QA I believe.

> > More to the point
> > there are libraries and modules all over the place.
> > The p_Procs_Field*.so modules are shipped in $bindir and some more
> > modules are shipped in $bindir/MOD this is not a traditional place
> > for that kind of files. A better place would be $libdir/singular or a
> > subfolder therein. There are libraries in $libdir and
> > $libdir/singular, why not put all the libraries just in $libdir? why
> > do some need to be in a subfolder?
>
> I agree that these files can be placed in a better location like
> $libdir/singular. I don't know if modifying the build system is enough
> to make the new scheme work. The singular executable needs to find
> these based on its current location. Perhaps as a workaround you can put
> the singular executable in this directory and make a symlink from
> bin/Singular.
>

That could be dealt with. I guess you would want some kind of relative
location. A sticky point is that it will have to work with either lib or lib64
so some code may have to be touched to take into account what $libdir is.

Francois

[Oleksandr]

Hi  Francois,

thanks for your interest in Singular spielwiese. 

Am Montag, 27. August 2012 22:48:00 UTC+1 schrieb François:

Couldn't see that file. But good old imagemagick display .dot files. As far as I
am concerned from analysing the symbols dependencies of the various libraries
it is incomplete (from memory). As I mentioned elsewhere the libraries are
badly underlinked - the problem is that there are a few circular linking
dependencies. Of course shared objects don't have to resolve all the symbols
until run-time but it is not considered good QA I believe.

Please take a look at the updated dependency diagram on slide 4 

at http://www.mathematik.uni-kl.de/~motsak/files/2012.Aug.Motsak_SW.pdf

please note that misc, reporter, coeffs and polys are to be considered as a single superpackage, which is called libpolys for now (sorry for confusion!).

We have eliminated as much circular dependencies as possible, 

so please do let us know about any bad interdependency you find.

> > More to the point
> > there are libraries and modules all over the place.
> > The p_Procs_Field*.so modules are shipped in $bindir and some more
> > modules are shipped in $bindir/MOD this is not a traditional place
> > for that kind of files. A better place would be $libdir/singular or a
> > subfolder therein. There are libraries in $libdir and
> > $libdir/singular, why not put all the libraries just in $libdir? why
> > do some need to be in a subfolder?

the point is that we currently distribute, build and install omalloc and factory, 

which are separate packages that are intended to be also standalone useable.   

> I agree that these files can be placed in a better location like
> $libdir/singular. I don't know if modifying the build system is enough
> to make the new scheme work. The singular executable needs to find
> these based on its current location. Perhaps as a workaround you can put
> the singular executable in this directory and make a symlink from
> bin/Singular.

That could be dealt with. I guess you would want some kind of relative
location.

yeah, all the resources (e.g. dynamic modules or libraries) are to be found relative to main executable or via system environment variables (see findexec == libresources)

 

A sticky point is that it will have to work with either lib or lib64
so some code may have to be touched to take into account what $libdir is.

p_Procs* and MOD/* are dynamically loadable resources (modules), which have nothing to do with the developers libraries (that go to $libdir), and

thus they might go to $libexecdir instead of $bindir if desired.

I hope this will help a bit. 

Thanks again for your feedback and contribution!

Cheers, 

 Oleksandr