Waldek,
In message <bobihq$na6$1@panorama.wcss.wroc.pl>, Waldek Hebisch
<hebisch@math.uni.wroc.pl> writes
>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 Poplog source tree is unified, in that each platform has a common
tree, such that the Pop sources are in $usepop/pop/src, the external
library sources are in $usepop/pop/extern, etc. The problem we have is
combining these in the repository, where one platform-specific file
cannot share the same name space occupied by it's equivalent from other
platforms. The solution I proposed, many months ago, was to incorporate
all platforms into the CVS with a standard $usepop directory tree
containing platform independent files, and platform-dependent files
being placed in their "normal" location, renamed with a
platform-specific suffix.
As far as I can discern, this is what you are proposing we do?
Back at Sussex, I believe they had a separate $USEPOP tree for each CPU,
OS, etc. These were then merged into a standard $USEPOP release tree for
building releases. The files were, I believe, stored in SCCS. I haven't
seen any scripts for extracting the files into the release structure,
but the mechanism they must have used is similar to the one we are about
to use.
I'm not yet convinced that there is a major functional difference
between storing the different platform name-spaces within a single
$USEPOP-style structure, with variants labelled according to
platform-specificity versus a set of platform-specific $USEPOP trees.
The latter can be treated as a set of simple tree merges, but applying
this to the CVS check-out mechanism will confuse the CVS records in the
developer's sandbox directory-tree. Similarly, the former requires an
iteration over the $USEPOP structure, appending increasingly
platform-specific suffixes to a directory element, to select the files
to check-out. This also does not sit well with the underlying
assumptions of the CVS sand-box. Either way, the developer needs a
mechanism to transfer files to and from a single-platform sandbox
$USEPOP tree in which s/he is working, to the CVS repository where the
structure has to be different to avoid name-space clashes.
>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.
>
Because we have separated files according to platform, allowing the
options of cpu, os and wm, we can mix-and-match to a certain extent. The
procedure to extract from CVS for a given combination needs to
reassemble the files into the standard $usepop structure, and vice versa
for checking files back into CVS.
>: 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.
I agree, and my existing process implements them as separate scripts,
but one has the option to invoke the other for those frequent occasions
when the processes follow sequentially.
>Existing tools for working with CVS are good enough IMHO. So Poplog
>really needs a configuration script, not a complex fetch-configure-build
>combination.
I disagree. The separation of files into platform-specific directories,
however these are categorised and named, means that CVS-extraction and
-insertion need an assembly/disassembly approach, beneath the hood of
which, lie the existing CVS tools.
You are right in suggesting that build is a separate operation.
>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).
>
Yes and no. The selection between "None", X-Windows and MsWindows
support equates to your choice of window toolkit, but the last is
currently implicit when selecting the "Windows" OS, which involves
compiling an entirely distinct external library subsystem. When I
suggested a "Window Manager" argument, I was considering the selection
between the support for X/Athena, X/Motif, PWM, a yet-to-be-implemented
KDE, etc.
We could compromise on the addition of a <window toolkit> parameter, but
then processing the combinations for the sparse few valid ones would be
unnecessarily complicated. I would suggest a simple enumeration of the
supported options, and if you want the argument to be called
"WindowToolkit", then that is fine by me.
>: 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).
>
I knew someone would go and have a look at the full tree, whereas I
looked at the tree I have sitting waiting to be uploaded, and report
back to me a much larger selection. Thank you.
>: 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).
A lot of work went into developing the support for X-Windows. Somewhat
less work, although, nevertheless substantial effort, went into
developing the Microsoft Windows support. If we have volunteers to
supply the effort to create the bindings to additional products,
whatever anyone wants to call them, then that is fine by me.
For the purposes of getting the configuration right, it might be useful
to enumerate the possible combinations of layers. We can then decide
which are supported already and which we'd like to add support for. I
don't suppose the following is complete, and there may be errors.
E.g.
Poplog
Poplog + X11
Poplog + X11+ Motif
Poplog + X11+ Motif + wxWindows
Poplog + X11 + Lesstif
Poplog + X11 + KDE
Poplog + X11 + wxWindows
Poplog + Tk
Poplog + X11 + Gnome
Poplog + GTK+
Poplog + GTK+ + Gnome
Poplog + GTK+ + wxWindows
Poplog + MsWindows + wxWindows
Poplog + Mozilla/XUL (and related technologies)
Poplog + OpenGL
Poplog + Qt
At this stage, I'm not sure what counts as a toolkit, a manager, a
general 2D or 3D graphics platform, a widget set or any other
categorisation. I'm not sure if, at the moment, Poplog makes any effort
to distinguish between the various layers. There is distinct, separate
support for MsWindows or X11, and there is the PWM, and there is support
for calling various layers of X11, including the widget set of the
current window manager. Additional facilities may need some further
generalisation of the X11 and Windows support to integrate them in a
coherent, extensible fashion.
>
>--
> Waldek Hebisch
>hebisch@math.uni.wroc.pl
Thank you for your comments.
Regards,
--
Jeff Best
|