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
|