Re: [PATCH 3/8] [rpm] force a configure before make distclean

["Jérémy Rosen" <jeremy.rosen@smile.fr>]

On 23/08/2016 19:16, Mark Hatle wrote:
> On 8/23/16 11:54 AM, Burton, Ross wrote:
>> On 23 August 2016 at 08:25, Jérémy Rosen <jeremy.rosen@smile.fr
>> <mailto:jeremy.rosen@smile.fr>> wrote:
>>
>>      -       ( cd ${S}/syck ; set +e ; rm -- -l* ; make distclean ) || :
>>      +       ( cd ${S}/syck ; set +e ; rm -- -l* ; ./configure ; make distclean )
>>      || :
>>
>>
>> Running configure without all the options it needs to actually work just so that
>> distclean works in a subbuild that shouldn't be breaking on rebuilds because we
>> have out of tree builds scares me a little.
>>
>> Mark, you added this line, can you remember what it was for?
> The syck version can be preconfigured, and if it is -- it's wrong.
>
> The 'set +e' is specifically in there to ALLOW it to fail.
>
> If it is configured, we much remove the junk and clean it.. if it's not been
> configured, we ignore the make distclean failure.
>
> So I'm not sure why it is necessary to make the change.  'Failure is permitted',
> and make distclean shouldn't be using any 'BUILD_CC' values from prior builds...
> since it's only wiping everything that MAY have been previously built and leaked
> into the release archive.
I havn't dived deeply on the whole chain of event, I have to admit that 
autotools scares me...

This particular line does work as expected. the set +e does indeed allow 
the make distclean to fail.

The problem is that if that distclean is not failing because nothing 
needs to be done it is failing because it can't find gcc. The junk isn't 
clean and the build of rpm will fail later complaining that the syck 
subdir is
already configured.

This is probably why you run the make distclean in the first place.

The need for gcc is weird... the error message I get is that no working 
version of gcc could be found, but the trace itself looks more like a 
call to configure (as if make distclean did some configuration check)

Again, I have not dug deeply enough in here to completely understand 
what's going on. I'd gladly take any clues you might have for a better fix.

>
> --Mark
>
>> Ross
>