[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 6 01:03:20 2003 
Subject:Re: [OT] CVS blues... was => Re: New poplog with bug in Pop-11/Poplog 
From:Jeff Best 
Volume-ID:1031106.02 

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