Re: gb gnat-gps_5.0-11 . armhf

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

Philipp Kern writes:
> On Mon, Jun 25, 2012 at 02:08:04PM +0200, Ludovic Brenta wrote:
>> On Mon, 25 Jun 2012 10:50:41 +0200, Hector Oron wrote:
>>>2012/6/25 Ludovic Brenta <ludovic@ludovic-brenta.org>:
>>>>Following instructions at [1] I hereby request that gnat-gps be
>>>>rebuilt on armhf.  The buildd killed the build midway because it was
>>>>taking too long for its taste.  This is a big package, taking
>>>>between 9 and 10 hours to build, but is OK otherwise.  Therefore, if
>>>>possible, please choose a buildd machine with several cores, lots of
>>>>physical memory and no hardcoded time limit on builds.
>>>It has been given back.
>> Thank you but what I explained happened again today on hildegard:
>> 
>> make: *** wait: No child processes.  Stop.
>> make: *** Waiting for unfinished jobs....
>> make: *** wait: No child processes.  Stop.
>> Build killed with signal TERM after 150 minutes of inactivity
>> 
>> Please, give back again or suggest another course of action.
>> I *cannot* and *will not* rebuild manually with every upload,
>> I can only do that in exceptional circumstances.
>
> The correct way is to output something as long as the build is still
> making progress.  Of course that shouldn't cause the buildd to be
> blocked forever if the build system fails midway.
>
> Currently exempting single packages from the timeout is a hassle and
> needs to be done on every possible buildd.

I've given thought to emitting more output during the build but, as the
buildd log indicates, the only output there is, currently, is the
invocation of gcc to compile each compilation unit.  I can't think of a
way to tell gcc to emit output while it processes a source file, when
that source file contains no errors and no warnings (which is a good
thing, right?).  Moreover, there is no telling which particular source
file gcc will be processing the next time the hardcoded timeout strikes.

I could cause gnatmake (which invokes gcc) emit more output *between*
compilation units but that will not help and cause the buildd log to
swell to tens of megabytes.  The gcc invocations are already emitted
between compilation units.

Any other suggestion?  I do have one but you might not like it any more
than I do: drop armhf from the list of architectures supported by this
package.

-- 
Ludovic Brenta.