[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 6 18:23:50 2003 
Subject:Re: [OT] CVS blues... was => Re: New poplog with bug in Pop-11/Poplog 
From:Waldek Hebisch 
Volume-ID:1031106.01 

Jeff Best (x@nospam.please) wrote:
: Waldek,
 
: In message <bobihq$na6$1@panorama.wcss.wroc.pl>, Waldek Hebisch 
: <hebisch@math.uni.wroc.pl> writes
: >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.

I mean that CVS tree should be equal to USEPOP structure (for me source
tree = USEPOP structure). So I would like to see something like 
$usepop/pop/src/Linux and $usepop/pop/src/i386. Minor point is that
I do not belive in things like src_SPARC_Solaris -- I think that 
SPARC dependencies can be easily separated from Solaris dependencies.
Major point is that IMHO variants should build from common USEPOP 
structure. With current structure to test a change made to i386 
version on Sparc one have to first commit change to CVS and then
update Sparc tree. Common USEPOP structure may be shared (say via
NFS) and changes can be tested immediately. With common USEPOP structure
one can use diff of two USEPOP structures to generate a patch and apply
it to a different architecture. 

: >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.
 
: >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.

That is exactly what I would like to change. I think that small change
to the build process can avoid shuffling files between USEPOP structure
and CVS.

: >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.

There are X servers for MsWindows also GTK more or less works on MsWindows.
Using Wine one can get MS compatible windows on Unix.

: 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.

Again I think that set of valid combinations while sparse is still quite
big. I am influenced here by GNU configure scripts. It is easy to find
people who hate GNU configure, but basic concept looks very good: before
build we configure program to include or exclude some features. Some 
features are clearily incompatible and can not be included together. 
Some subsets of features works like radio buttons -- one has to choose
exactly one target cpu. A configure script typically is able to find
"good" combination of features, but if needed the user can choose 
differently. GNU tools typicaly specify target system as triple 
consisting of CPU, vendor and OS. In my opinion vendor part is 
really redundant (when used it is really vendor variant of CPU or
vendor variant of OS). So we have CPU and OS. For native build 
both can be autodetected. IMHO CPU and OS are really ortogonal 
to other features. But the other features are too irregular to
put them as single argument choosing the whole combination. It
is better to have a separate agument to request or exclude given
feature, with constraints like --with-motif implies --with-x. 
Ideally _all_ configuration arguments are optional. 

: >: 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.

I think that two aspects should be separated: what user can do and what
Poplog itself (mainly ved) uses. When talking about bindings I stress 
the first aspect. AFAIK low-level bindings are rather easy to write
(low-level basicaly means wrappers around external calls) and while not
very elegant can give many practical benefits. Binding which plays nice
with the rest of Poplog needs more effort. Making ved use such binding
is probably even more effort. 

Coming back to configuration: by default configuration script should
include all bindings that works (together) on build machine. In case
of conflicts default preferences are needed. Each binding should be 
a separate feature whith conflicts (if any) and dependencies. That way
"Window Manger" or "toolkit" category is not needed at all. I still 
think that "Window Manger" in not good, but after the previous post
I realised that such category is really subsumed by feature mechanism.
 
--
                              Waldek Hebisch
hebisch@math.uni.wroc.pl