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

Waldek,

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

For reasons of getting *something* uploaded top the CVS so that others 
could check it, I uploaded entire x86 Solaris distribution before I had 
the time to run a process to check which elements were common. I 
recognise that this is/wasn't the best way to do things, but it seemed 
to be a good idea at the time.

I was expecting the final repository to contain a single corepop binary 
for each platform, allowing an easier rebuild. At the time I developed 
this expectation, I had yet to build the Windows version from scratch. 
Part of my problem was that the build scripts used a previously built 
corepop to determine platform-specific variables that drove the current 
build process. I have since modified the build scripts to resort to a 
shell-specific version of this evaluation if corepop fails or is not 
present, and I can now rebuild the Windows Poplog from scratch without a 
previous version.

I have been building a test suite, with the aim of making it available, 
over the Net, to Poplog developers. So far, I have Windows 2000, x86 
Solaris 9 and SuSE Linux 8.2 PCs for this purpose. I need to reinstall 
my network (which I dismantled just before our recent move), and install 
some form of secure VPN access. I'm a little hazy about how to do the 
latter.

When I have got the test facility working, I'm prepared to go cap in 
hand to a few suppliers to ask if they'll lend or donate machines for 
developing and testing their platform's versions of Poplog.

>I belive that many OS variations can be handled in similar way, and
>the harder ones needs OS specific directory (for symmetry we can
>make OS specific directories for all OS-es). I think that thare is
>no need to have files which are both CPU and OS specific.
>

At the time of creating the first draft of the repository, I was more 
concerned with getting *something* available in order to encourage 
others on board, and lacked the time to complete the platform-comparison 
I needed to do to eliminate duplication. Now that you have kindly done 
this for the x86 Linux and x86 Solaris pair, I can go ahead and 
eliminate the duplication.

When I first tried merging in the Windows, Solaris and Linux versions, I 
immediately hit the build process's use of wildcards to determine what 
to compile. This makes it include inappropriate files belonging to other 
platforms, and the build falls over.

>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.
>Confusion resulting from duplication raises difficulty even more.
>

In principle, I agree. After my response to your last raising of this 
point, I also recalled the additional reason for choosing a flattened 
tree approach, which was that a check out of $usepop/src would give you 
every platform's code, whether you wanted it or not, whereas the 
checkout of $usepop/src, %usepop/src_CPU, $usepop/src_OS and 
$usepop/src_CPU_OS should give you just what you want at the expense of 
a few extra check-outs, all of which could easily be automated. At the 
time, I wasn't certain of the implications of this to the correct 
maintenance of the CVS directories in the developer's sandbox where all 
the check-outs were going to go.

I am also aware that there is too much duplication in what's already 
been checked in, and I've given the reasons why this happened, above.

I share your desire to eliminate duplication. I'm not sure to what 
extent we can safely preserve links within the CVS. I am also not 
certain of the correct hierarchy, if we choose to adopt a non-flattened 
directory tree, that will encompass the correct set of platform 
dependencies. It would be helpful to enumerate them. You have started, 
with your comment that the x86 Solaris version is/should be the x86 
Linux version with an appropriate $usepop/src/syscomp/sysdefs.p.

If we can revert to this alternative approach, which is the one I 
started with, and modify the build process to eliminate wildcard file 
selection, with simple file suffixes and links to select 
platform-specific variations, then I'd be very happy to see my flattened 
tree branches go..

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

Regards,
-- 
Jeff