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

Waldek,

In message <boe3jm$hnk$1@panorama.wcss.wroc.pl>, Waldek Hebisch 
<hebisch@math.uni.wroc.pl> writes
>
>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.
>

My solution always envisaged the options src, src_SPARC, 
src_SPARC_Solaris, src_Solaris, etc. There are some differences between 
SPARC_Solaris and x86_Solaris, as well as some similarities. By 
flattening the tree, so that everybody could see that names were to be 
built in the order of CPU, OS, "X" (where X may become a variable 
indicating window tool-kit), we wouldn't end up with one developer 
creating src/SPARC/Solaris and another creating src/Solaris/SPARC and 
wondering why his changes didn't seem to work. Of course, somebody could 
still create a src_Solaris_SPARC directory, but they would be doing it 
in the visible presence of a src_SPARC_Solaris and our sympathy would be 
appropriately muted.

Your solution probably looks neater. My solution needed a supplemental 
class map to indicate where, for example, src_MacOSX should also look 
for src_BSD files. Even with your solution, I think we would still want 
to separate those dependencies into a single, manageable file.

Either solution requires a process to go and create links to or copies 
of specific files in the $USEPOP namespace location where they are 
expected to be.

Either solution requires a change to a platform-specific version of a 
file located in its proper slot in the standard $USEPOP namespace to be 
relocated to it's repository namespace location for checking in.

I don't like the solution with flattened tree names, but experience 
tells me that trees that are only normally visible a node at a time give 
rise to lots of problems that shouldn't ever occur. Perhaps in academe, 
we can rely upon a greater concentration of common sense and therefore 
either approach would work.

Functionally, both solutions would work. Yours has the edge if we want 
to eliminate, link to or move an entire subtree of the $USEPOP 
repository namespace so, on balance, I think I have to endorse your 
suggestion.

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

That depends upon what you mean by configuration. We (will) have a 
repository namespace containing all the files for several platforms, a 
development namespace containing all the files for some platforms, and a 
number of run-time namespaces containing just those files required for a 
pre-defined installation. A run-time namespace can be viewed as a 
selection over a development namespace, whereas the development 
namespace can be viewed as a projection. The process of transferring 
files from the repository namespace to either a development or a 
run-time requires some mapping to achieve the projection that stops 
platform-specific elements competing for the same namespace slot.

Later, when building systems, we populate namespace slots with new 
files.

There are two configuration processes involved. One determines where the 
namespaces, and subtrees of a namespace, are to be located within the 
target file-system. The second controls the build process.

As a consequence of both of these processes, a run-time configuration 
results, and this needs to be recorded for users to source.

If we adopt measures similar to many projects, with INSTALL, CONFIGURE 
and BUILD procedures, then we could certainly take your approach. In the 
end, it is probably easier to run a CONFIGURE process, with a series of 
questions and answers, than to make sure that scripts are invoked with 
complete and correct arguments.

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

That's not a bad idea. Changing the build process to iterate through the 
various subtrees that may contain appropriate sources would certainly 
avoid the mapping problem. This would be a further argument to using 
full file trees instead of my flattened tree approach.

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

I think I now agree with you. To handle the combinations that we may 
support, a configure process would be best. With a unified CVS $USEPOP 
tree, many of our current problems disappear.


[Debate over categorisation and naming of window/graphic features]
>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.
>

I accept the criticisms of the name and reluctantly forgo the simplicity 
of "WM" for the abbreviation. I am persuaded that we do need a database 
of features, bindings and dependencies and a configuration process that 
uses it.

>--
>                              Waldek Hebisch
>hebisch@math.uni.wroc.pl

Regards,
-- 
Jeff