[OE-core] [PATCH 3/8] [rpm] force a configure before make distclean

[Mark Hatle]

On 8/24/16 2:44 AM, Jérémy Rosen wrote:
> 
> 
> 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 at smile.fr
>>> <mailto:jeremy.rosen at 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.

Make often has a rule looking at the time stamp of specific files and re-running
specific autotools if they are 'out of date'.  That COULD be the cause of the
errant call to gcc?

I have not observed the above occurring -- but the key thing is that syck needs
to be cleaned of the generated files.  We don't want to run any host commands
other then clean it.

If you have to replace it with something else, you will need to identify all of
the files that need to be cleaned and manually remove them avoiding the
distclean call.

Easiest way to do that.... extract the source for syck, back it up, run the make
distclean.. compare the difference and use that list as a replacement 'cleanup'
command.

--Mark

>>
>> --Mark
>>
>>> Ross
>>
>