Jeff Best (x@nospam.please) wrote:
: There is an outstanding "CVS" job, which I started a while back and then
: got side-tracked away from and I'm still working my way back to it.
: We need a script to get the files for a given CPU, OS (and, optionally,
: Window Manager), and generate a release bundle. This should use a Bourne
: shell, in order to run virtually anywhere. OpenVMS and Windows will be
: exceptions, but they could use the same script to just fetch the
: relevant files. The script should probably be driven by its own list or
: tree of Poplog directories, with some logic to test for versions of
: these with a _<CPU>_<OS>[_<WM>] suffix. An option to bundle the fetched
: tree into a compressed tarball would be useful.
: The script could then be run on their local machine, by anybody wanting
: the latest files comprising a specific version of Poplog. The arguments
: would be:
IMHO the Poplog source tree should be unified, otherwise the resulting
tree will be unmanagable. Each CPU (and possibly OS) should have own
subdirectory. Important point is to be able to mix all possibilities.
Minor differences can be handled by conditional definitions, major
warrant separate files or subdirectories.
The configuration script should just generate few files containing
path and definitions driving conditionals in other files. In first
stage it may set up some links. The link farm approach currently used
requires very specialised tools so IMHO is not apriopriate for open
developement.
: 1 CVS Repository, e.g. cvs.sourceforge.net connection string
: 2 Local target directory for fetched tree.
: 3 Optional CPU
: 4 Optional OS
: 5 Optional Window Manager
: 6 Optional Flag (including a compression program name) to request a
: compressed tarball, e.g. -c[bzip2|zip|compress|compact]
IMHO fetching archive and configuration are really separate tasks.
Existing tools for working with CVS are good enough IMHO. So Poplog
really needs a configuration script, not a complex fetch-configure-build
combination. Also Window Manager category really is not a good name.
AFAIKS what matter is window toolkit. Since some window toolkit go
much beyond user interface it makes some sense to use to of them
together (say Gnome GUI and some non-GUI KDE parts).
: If the user declines to supply arguments 3-5, then the script could do
: some investigation to determine the client's values.
: As far as possible, the minimum facilities should be assumed available
: on the client machine, to ensure that the script has the widest possible
: chance of running on all platforms.
: The supported CPUs are* x86, SPARC, PPC and Alpha.
AFAIKS the 15.53 source tree contains support for: alpha, hppa, i386, mips,
m68k, ppc, sparc, vax. I do not know if anybody still uses vaxes, but
the others seem very much alive (for example have rather complete Linux
distribution).
: The supported operating systems are* Windows, Linux, HPUX, Solaris, AIX
: and VMS.
: The supported window managers are* Motif or KDE.
Again, that is window _toolkits_. And really, Poplog should provide
bindings to various toolkits (TK, Gnome, KDE) without forcing to
use a sigle one. And an option to use X without a large toolkit
(currentely present) is an important one (think about resources used).
--
Waldek Hebisch
hebisch@math.uni.wroc.pl
|