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

Aaron,

In message <bomg8t$o55$1@soapbox.cs.bham.ac.uk>, A.Sloman@cs.bham.ac.uk 
writes
>Waldek Hebisch wrote:
>
>> I fetched a nightly CVS tarball on November 1. When I looked at differences
>> is seems that src_x86_Solaris directory is just an obsolete version of
>> src_x86_Linux directory. *Both* directories contain full support for
>> x86 Linux and x86 Solaris. Solaris directory contains binaries (which
>> should not be present in CVS) and appearently lacks few fixes applied to
>> x86 version. To build one have to choose (link) correct
>> $usepop/src/syscomp/sysdefs.p file. The rest is handled by conditional
>> compilation.
>
>I wonder if anyone is using the x86 Solaris version of poplog? I don't
>think it was ever part of the main source tree at Sussex, and was
>put together at sussex as a special favour for one or two users.
>
>The only version of this in the Bham Poplog directory is
>       http://www.cs.bham.ac.uk/research/poplog/new/pcsolaris1552.tar.gz
>       12580609 bytes Aug 30  1999
>
>It is not included in
>       http://www.cs.bham.ac.uk/research/poplog/src/master
>
>but the vast majority of the sources will actually be in the
>       S.pcunix/
>directory, which includes also linux sources.
>

I have version 9, and will be using it. Sun have just raised the profile 
of x86 Solaris, and I believe the uptake has been encouraging. I have 
yet to install Poplog on the machine.

>
>I have been thinking about this. Instead of the hard links that we
>currently have, in the source tree, which easily cause mistakes (e.g. if
>a file is renamed and then a replacement inserted), I suggest we have a
>source tree that is shared by all versions. All files that are common to
>all versions of poplog will be in the usual locations.
>
>Every file that is EITHER CPU-specific or OS specific will be in a
>subdirectory with the name of the CPU or the OS, prefixed by 'CPU-'
>ir 'OS-', e.g. 'OS-Solaris'
>

If the file is, for example, sysdefs.ph, I think that an extra directory 
for it is overkill. A simple prefix or suffix would do the job, e.g. 
sysdefs_<CPU>_<OS>.ph.

>Versions of the same OS should be handled by conditional computation.
>

I agree.

>Some 'psuedo' OSes may have to be invented, e.g. 'OS-unix' could cover
>stuff for all versions of linux and unix with conditional-compilation
>where appropriate.
>

However we do this, we will trip up over the combination of systems. 
E.g. Some OS + Gnu, such as Windows + Cygwin. This was my original 
reason for rejecting a pure hierarchy of platform-specific directories.

>I presume that for this purpose we'd have to treat cygwin as an OS ?
>

I'm still not sure. We obviously need the Windows-specific external 
stuff in %usepop/pop/extern, but we also need the X-Windows and Windows 
stuff in both $usepop/pop/x and $usepop/pop/win, along with appropriate 
sub-sections of the library, and we also can use the Unix set of 
shell-interface files from $usepop/pop/src.

There is also the version of Windows with Microsoft's Unix utilities 
support to consider. Normally these have to be paid for, except, I 
believe, by educational users, so the only person I know who has 
mentioned using them was Anthony.

>This means that no files need to have a special file name with extra
>suffixes, which could cause problems on some operating systems with
>limited-length file names.
>

OK. We may have to have a tree.

>If there are any files that are both CPU and OS specific (e.g. if some
>of the assembler files for a particular CPU take different versions for
>different operating systems, in a manner that cannot be handled by
>conditional compilation mechanisms), then the OS versions will be in
>subdirectories of the CPU versions.
>

Agreed, but I also agree with Waldek's caveat, that where possible, we 
should merge the files and use conditional compilation, although, having 
said this, eliminating the bug that stops c_core.c compiling under 
Cygwin has been sufficiently complex that I haven't yet found a 
long-enough time-slot to complete the task.

>Then, to create complete system for a particular OS+CPU combination, a
>script will copy over the contents of the whole tree except that
>where directory names specify any other OS or CPU their contents
>will be ignored as irrelevent and the contents of relevant
>directories will be installed as if they were in the nearest
>non-OS and non-CPU specific super-directory.
>

This approach will require, either as check-out of everything, because 
an element of $usepop now contains a tree of platform variations, or, a 
tailored check-out routine that explicitly requests individual files 
and/or directories. We may be able to do this by CVS labelling. I'll 
look into this, unless anyu reader has immediate knowledge of how we do 
this.

>I think this method is simpler than having to do truncation of file
>names: instead it uses truncation of path names. But I won't know for
>sure that this is simpler till it's tried.
>

Agreed.

>Another option would be to keep the files in the sub-directory where
>they are installed, and merely insert symbolic links to them. E.g.
>
>       cd <path>
>       ln -s <CPU-type>/* .
>               (then remove new links that refer to a directory)
>       ln -s <CPU-type>/<OS-type>* .
>
>Finally
>       ln -s <OS-type>/* .
>
>If the linking method is used, then no file name or path name ever needs
>to be changed when building a package, only links inserted. I don't know
>if that will work on windows.
>

This would only work where all of the files in a part of the $usepop 
name-space had no platform-specific variants that needed to 
replace/overwrite them. This may be the case, but could be a hostage to 
fortune.

>This also solves the problem of testers having to work with one file,
>and then installing another file.
>

If we can use links, then I agree.

>The developers will work in a system that has files in the right places,
>but with extra symbolic links.
>
>When installing something into sourceforge only the file not the
>link will be installed.
>

But the information about the links needs to be stored somewhere. I 
would prefer a system that used a database (i.e. a simple file) of link 
information, with a generic script for processing it, rather than a 
script that hard-wires the link information via a set of ln statements.

>> I want to make my point once more: there should be _NO_ duplication
>> in the source tree. With unified source tree a little effort is
>> enough to support many variants. Duplication means duplicated effort.
>
>Agreed. The above scheme avoids most duplication.
>

Waldek, would you like to do any of the conversion work? If so, I can 
add you as an administrator to OpenPoplog if you can register with 
SourceForge and give me your registered username.

>Aaron
>
>
>

Regards,
-- 
Jeff