Merge ROPP BUILD?

[Dave Offiler]

The main ROPP release tarball unpacks the distro bits of ropp_bld into the root working directory alongside the individual ROPP module directories. Users then copy dependency tarballs here and use build* tools to build/install the dependency & ROPP packages. For local development, it is normal to copy the ropp_bld files, checked out of SVN separately, to the checked-out ropp_src root, to achieve the same setup (or manually run a mini-script from ropp_bld to configure, followed by make, which is more efficient for development, especially when only needing make when testing a code change when the configure & make install steps are not needed)

This last step confused Stig, who is starting to use SVN for the first time, rather than the packaged tarballs. He suggests merging ropp_bld into ropp_src, so first-checkout would emulate the user setup from tarballs.

On the face of it, this seems a logical idea. ropp_bld is historically separate because it started as a toolkit for developers, not for users, then we released the configure scripts and a basic assist for users, merely as examples. Since then, these tools have become integral to the build to the extent that we highly recommend them to users (and hint that they are on their own, support-wise, if they don't!)

One possible option short of a full merge would be for a developer to check out ropp_bld directly into ropp_src (into the root of the latter, not as a sub-directory like the other modules). However, this might cause a clash of files, so this needs to be checked. The Trac wiki page would merely need to document this procedure. Separate check-out would still be possible so that the mkdistro script could work as now.

A better option would be to fully merge the current ropp_bld files into ropp_src under the latter's subversion control (and then drop the separate ropp_bld from SVN).

Unless kept separate, the mkdistro script would need to be modified to pick up files for tarballs (at least for the main one) from the new location in ropp_src. This should be trivial.

Currently, we provide a separate ropp_bld tarball to help users build the individual ROPP module tarballs. Rather than provide a stand-alone build package, we might package build support into each module tarball (the overhead is trivial). A disadvantage is that a user would have to untar the module before getting access to the build scripts - buildpack unpacks tarballs. However, a user anyway has to unpack the stand-alone build tarball now, so it would just be a different tarball; having unpacked one ROPP module (and installed dependency packages), the build support could then be used to unpack & build any other ROPP modules.

The options should be looked into for pros & cons and a proposal put to the development team, and actioned according to agreement. Note that this is a re-packaging matter which would have little impact on developers (beyond some efficiencies working), and none on users, so is not a priority task.

On a related packaging issue, I find it a pain that having unpacked the main tarball to (e.g. ropp_5.0/ the individual modules' sub-directories are named ropp_utils-5.0/ etc. Could/should these sub-directories (or the main package only) be named just ropp_utils/ etc? (The individual module tarballs should still unpack to the versioned names, since we have no control over where a user unpacks them, and could accidentally over-write a previous version.)

[Ian Culverwell]

For what it's worth, I (Ian C) would favour a full merge of ropp_build and ropp_src, but only in the long term - by which I mean CDOP-2. It's logical and closer to the general user's experience of ROPP. For the same reason I agree that having ropp_utils_5.0 for the users and ropp_utils for the developers is a bit tiresome.

However, I think we should be at a "breathing stage" of the project, eg the gap between CDOP1 and CDOP2, before implementing a no-science-but-lots-of-system-work change. This opinion is reinforced by the fact that Stig Syndergaard at DMI has written a script to allow developers to build ROPP in a similar way to that in which general users use buildpack - see attached.

[Dave Offiler]

Since I already had almost all files in ROPP_BLD copied into ROPP_DEV (current v51_prototype branch) I've gone ahead anyway and copied the remainder over. I've created a ropp_build directory in parallel with the main source modules, but this is to make the build look like the other source modules to some of our development tools. In particular:

• the 'build' option to makedistro is now merged with the other ropp source options; the new directory catches some common files which are copied to all modules (but can be ignored for the ropp_build tarball) and contains the Makefile (which only makes the ropp_build tarball).
• roppauto and roppconfig updated to ignore ropp_build
• added Stig's script (with some mods)

Tested makedistro with 'build' & 'utils'.

The renaming of modules to remove the version number in the meta-package is left for a future update as a separate (and minor) issue. Checked in as [3007].