Re: GSL 2.0 roadmap (one man's view)

[Gerard Jungman <jungman@lanl.gov>]

On Thu, 2009-09-03 at 19:19 +0200, Brian Gough wrote:
> At Thu, 27 Aug 2009 17:15:39 -0600,
> Gerard Jungman wrote:
> > * Better overall organization, expression of module dependencies, etc.
> 
> I would be happy to remove the goal of independent sublibraries from
> the design document--it doesn't reflect reality. 

There are really several (partially) independent issues, all
touched by the "Better organization" point. They relate to
the build system, module dependencies, and the overall user
experience.


> I am not clear what benefit it would provide to users now anyway--is
> there actually a problem with "one big library"?

Yes, there is. As soon as GSL learns to talk with the rest of the
world, dependency issues will arise. Sub-libraries should be
insulated. Think of how something like a dependency on lapack
might propagate through the system.

There are related problems, related to dependencies and
the nature of the build, which can be addressed by
compartmentalizing the installation. This is helpful
to package maintainers, whether they are preparing packages
for a major distribution or they are local ad-hoc
packagers, down to the level of one user.

Simply put, the build and installation should be more modular.


> If you want to avoid the symbolic linking of header files we could
> just move them into the gsl/ directory instead of keeping them in the
> individual subdirectories. (While the symlinks are ugly I don't think
> they have ever actually caused a problem for anyone.)

This is the upside down solution. The right way is simple; just change
the includes to be hierarchical, so that client code would look like

  #include <gsl/interpolation/gsl_spline.h>

We talked about this 12 years ago, but we couldn't figure out how
to get autotools to do this properly, for build and/or installation.
Maybe somebody knows how. Maybe we should discard autotools.
That should certainly be discussed.

--
G. Jungman