id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
249	Merge ROPP BUILD?	Dave Offiler	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.)"	task	closed	minor	5.1	Build	5.0	fixed	ropp_bld, ropp_src, build, tarball