Hi Jan,
Чт 30 апр 2020 @ 15:33 Jan Wielemaker <j.wielema...@vu.nl>:
> On 4/30/20 3:10 PM, Lev Lamberov wrote:
> > Recently I was (again!) approached by some embedded developers who asked
> > to provide Core_system as a separate package and try to break
> > swi-prolog-nox into several smaller packages.
> >
> > Currently, I'm thinking about breaking it into swi-prolog-core
> > (containing Core_system), swi-prolog-core-packages (containing
> > Core_packagse; depends on swi-prolog-core) and swi-prolog-nox
> > (containing other components from the original swi-prolog-nox; depends
> > on swi-prolog-core and swi-prolog-core-packages). What do you think
> > about it?
>
> As long as swi-prolog-nox still provides a useable Prolog system I'm
> happy. I would go with Jonas in that case though and have yet another
> basic package that just contains the shared object and possibly the main
> executable and boot file (swipl.prc)
>
> Just the shared object is enough to create runtimes when using
> --stand-alone as this creates a file that starts with the swipl
> executable. Adding the swipl executable to the base package allows to
> start the state with some option and makes the state smaller (but not
> much, `swipl` is really short). Adding the boot.prc file adds only 90Kb
> and actually allows running Prolog. Without libraries, but you could
> distribute the essentials with some application as .pl or .qlf files.
>
> If we rethink from the start, my ideal is that "swi-prolog" creates a
> pretty much complete installation, including xpce (gui, ide). Yes, there
> are quit a few dependencies, but virtually every desktop installation
> has most of these installed anyway.
>
> Then we can have some hierarchy below that. Some parts are clear, but
> the real dependencies between the various packages is largely unknown
> and easily varies between versions. If you are interested I could come
> up with some meaningful splits.
>
> Bottom line should be just the real core (as above), which is enough to
> run saved states. You than have two options for saved states relying
> on foreign packages: include the package in the saved state or install
> the package.
So, my proposal is to have to following packages:
1. swi-prolog-core (with Core_system)
2. swi-prolog-core-packages (with Core_packages), depends on
swi-prolog-core
3. swi-prolog-nox (original swi-prolog-nox, but without
swi-prolog-{core,core-packages}), depends on
swi-prolog-{core,core-packages}
4. swi-prolog-x (without changes at the moment)
5. swi-prolog-java (without changes at the moment)
6. swi-prolog-bdb (without changes at the moment)
7. swi-prolog-odbc (without changes at the moment)
8. swi-prolog-doc (without changes at the moment)
9. swi-prolog-test (without changes at the moment)
10. swi-prolog, depends on swi-prolog-{nox,x} as we have now
11. swi-prolog-full, depends on swi-prolog and
swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
except swi-prolog-test)
Later we can break swi-prolog-nox into smaller parts, but I don't think
it is necessary to do this now. I'd prefer not to hurry with these
changes, let's have it as a goal for the next Debian release.
Another thing mentioned by Jonas is that swi-prolog-nox depends on -dev
packages (libedit-dev, libgmp-dev, libncurses-dev, libreadline-dev).
These are development libraries, that is they contain header files to
link against these libraries. This requires installing some other
development packages. Moreover, sometimes development packages are
somewhat large (say, installed size of libgmp10 is 579 KB, but installed
size of libgmp-dev is 1952 KB). So, one of the arguments of breaking
swi-prolog packages into smaller parts is that it will make possible to
install only what is needed also in terms of development packages.
Cheers!
Lev
