Re: [Chicken-hackers] [PATCH] Delete stale binaries when cross-building eggs

[Felix]

From: Peter Bex <address@hidden>
Subject: Re: [Chicken-hackers] [PATCH] Delete stale binaries when 
cross-building eggs
Date: Mon, 29 Apr 2013 19:00:20 +0200

> On Mon, Apr 29, 2013 at 03:41:11PM +0200, Felix wrote:
>> When cross-building extensions from a local directory (instead of
>> downloading) and the setup script uses make(1) or the "make" egg, or
>> may otherwise be influenced by files produced during the build, then
>> the 2nd (target) build may fail due to binaries left by the 1st build,
>> or the 1st may have leftover binaries from a previously built target
>> ... you get the idea.
> 
> Could you elaborate a bit?  For example, I don't understand why this is
> a problem specifically for cross-building, and why make can't deal with
> this via timestamps and/or a "clean" target?  I'm probably missing
> something important here.

An egg that uses make(1) or the "make" egg will only build parts of
the egg (usually one or more *.so's) when necessary. When building
eggs freshly from the server this is not a problem as the
build-directory will be clean.  When building from a local egg
directory (e.g. chicken-install -r xxx; cd xxx; chicken-install) in a
usual environment this is also not a problem. But when cross-building,
the *.so's will be built twice: once for the host system and once for
the target. If the architectures are different AND you build for the
host OR the target (you can build your egg with a
"cross"-chicken-install separately, for target, host or both) AND you
have binaries in that local directory that are leftover from a
previous build for a different architecture THEN it may happen that
the 'so's are up to date but for a different architecture.

So the safe thing is to nuke everything that looks like a binary
because you can never know what is lying around from a previous
installation or installation-attempt.

Sorry, I'm currently unable to describe this problem in a clearer
manner.


cheers,
felix