I committed these changes; let me know if any problems.
-- David

On 31-Dec-2012 2:15 PM, "Steffen Möller" wrote:
Dear all,

I just received a kind reply from David suggesting to publicly discuss the
consequences of my patch to the <server code directories>/Makefile.am files.
The current "make install" instructions are incomplete in that they do not
copy all the files that need to by copied - most prominently the html
directory but also various others in sched and tools. And it copies files to
directories where "make_project" does not expect them. The attached patch
(against yesterday's HEAD of the git repository) fixes all that, but David
indicated that it may interfere with other ideas on how the "make install"
for the server parts would be used.

The motivation behind the patch was to have at $(prefix)/$(somewhere) with
somewhere=lib/boinc-server-maker (should become a configure option, I
propose) a collection of all files that "make_project" expects, i.e. also the
html files which do not even have a Makefile.am and hence are not installed
anywhere. More severely, files expected separately by make_project in sched,
tools and vda are today found together in /usr/bin. Many hours were
previously sunk into separating them for the boinc-server-maker package that
we once uploaded, and with build instructions which then were soon rendered
obsolete with any later release. With the patch, the Debian packaging would
instead take everything for the boinc-server-maker package from a single
location and that is it: the boinc-server-maker package is ready, server
packaging issues solved by "rm *", basically. This means, all the server
logics for the Debian/Ubuntu packages remain within the BOINC source tree,
which should considera

bly help the adoption of those ready-to-use server packages.

With my testing (and consequently also with the tutorial on
http://wiki.debian.org/BOINC/ServerGuide) I did not get any much further than
calling 'make_project'. This now works like a charm - without access to the
checked-out source tree. Reasons speaking against any such approach please
summarise in a quick reply.

Many thanks and best wishes for 2013+

Steffen



_______________________________________________ boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe,
visit the above URL and (near bottom of page) enter your email address.

_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to