On 04/13/14 08:36 AM, Kevin Zheng wrote:
Hi Kari,
On 04/13/2014 05:14, Kari Pahula wrote:
Crossfire 1.71.0 server is unbuildable without the arch directory.
Here's what happens in lib/ directory (from make -d's output):
In short, install-data-local requires smooth, which requires
.collect-stamp, which gets created with touch. Then smooth's rule
decides that smooth needs to be regenerated since .collect-stamp is
fresher than smooth, making the build fail since there's no arch
directory.
Thanks for going through all the trouble to figure out what's wrong. It
is indeed a missing dependency-tracking file ('lib/.collect-stamp') in
the distfile. I must have missed it when creating the tarballs.
In theory, make dist should collect everything that is necessary (that said,
all too often things tend to fall through cracks which are discovered at release
time).
This would work if there was a lib/.collect-stamp with a correct
timestamp included with the server package, but there isn't. I could
suggest that it wouldn't be a dot file since it wouldn't get waylaid
so easily then. But this part would, IMHO, work even better without
using a stamp file at all. The collect.pl script generates a fairly
limited set of files and you had listed them already in the
Makefile.am file itself. I'm not sure how make -jn friendly the
current code is, either.
The current archetype collection process is hackish and fails when
running with multiple build jobs. I was thinking that the collection
process should be moved out of the server build process altogether.
It is part of the build process because it is needed for the server to run.
However, I'm not quite sure why we never did something like this in the
Makefile:
if [[ ! -e arch ]]; then
echo "No arch directory found - skipping collection"
else
<normal collect logic>
fi
I suspect there is probably some makefile magic that could be done to fix the
'gmake -j4' type issue - something to say that that single command is used to
generate this file, so don't run multiple versions at same time. Or perhaps at
least for the lib directory, something that just explicitly disables
parallelism, since nothing is really built in that directory.
All that said, the collect logic isn't great - it doesn't have any way to know
if the files in the arch directory have changed, so in that case, the server
admin has to know to run an 'make collect' by hand if they know the files have
change.
There is also some different situation here from SVN vs releases - in SVN,
there is no precollected files, so by definition, a collection will be needed -
which is not the case for official releases.
I ran into this while packaging 1.71.0 for Debian. I worked around it
by calling touch -t 197001010101 lib/.collect-stamp before building
the server.
This workaround also works for packaging on FreeBSD. Do you think I
should roll a new tarball with '.collect-stamp' included?
I don't think it is worth the effort - I'd perhaps just put out a notice like
'the lib/.collect-stamp file is missing. Before compiling this release, do a
'touch -t 201401010101 lib/.collect-stamp' and all will be good.
That is such a simple workaround that it shouldn't be any problem. For anyone
making official binary releases, this won't be a problem in the release - just
the packager will have to know this step.
_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
