[crossfire] Building crossfire 1.71.0 server fails without arches

[Mark Wedel]

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.