Re: build failure

[Ben Abbott]

> On Jun 25, 2016, at 11:45 AM, John W. Eaton <address@hidden> wrote:
> 
> On 06/24/2016 10:44 PM, Ben Abbott wrote:
>>> On Jun 24, 2016, at 8:54 AM, Ben Abbott <address@hidden> wrote:
>>> 
>>>> On Jun 24, 2016, at 08:39, c. <address@hidden> wrote:
>>>> 
>>>>> On 24 Jun 2016, at 03:28, Ben Abbott <address@hidden> wrote:
>>>>> 
>>>>> I tried jwe’s earlier suggestion to me, and it worked.
>>>>> 
>>>>> $ make libinterp/corefcn/oct-tex-parser.cc
>>>>> YACC     libinterp/corefcn/oct-tex-parser.cc
>>>>> updating libinterp/corefcn/oct-tex-parser.output
>>>>> updating libinterp/corefcn/oct-tex-parser.h
>>>>> 
>>>>> Ben
>>>> 
>>>> Thanks, this worked for me too!
>>>> 
>>>> But if I delete the whole build directory then do
>>>> 
>>>> configure && make
>>>> 
>>>> I still get the problem so there might still be something
>>>> to fix in the build process?
>>>> 
>>>> Shall I submit a bug?
>>>> 
>>>> c.
>>> 
>>> Yes. There is a problem building from scratch. I assume this is a blocker?
>>> 
>>> I'll browse the makefile when I have time and see if I can determine where 
>>> the logic is failing.
>>> 
>>> Ben
>> 
>> Carlo, does the attached work for you?
>> 
>> John, does the attached changeset look correct?
> 
> Does it work for you?  That's the same kind of dependency that is listed for 
> oct-parse.{h,cc,yy}, but it still doesn't solve all the problems for me.  I'm 
> also not sure why the rules for oct-parse and oct-tex-parser were different.
> 
> In any case, the .h file doesn't really depend on the .cc file, so that's not 
> the correct dependency.  It does solve the problem of being able to do
> 
>  make oct-tex-parser.h
> 
> when oct-tex-parser.cc does not exist because the dependency chain will then 
> cause the .cc file to be generated and, as a side effect, the .h file will 
> also be created.  But this change doesn't solve the problem of creating the 
> .h file when it is missing but the .cc file is present.
> 
> What we really want is a set of rules that tells make that %.h and %.cc are 
> both generated by one invocation of bison so that the rule is triggered (but 
> only once!) when either or both are missing.  The suffix rules generated by 
> automake rules don't do that, and I don't think there is any way to make a 
> suffix rule do that properly.  So I think this is really an automake bug, but 
> one that is not likely to be fixed unless it becomes possible to generate 
> modern GNU Make style Makefiles.
> 
> I checked in the following changeset in an attempt to work around the problem:
> 
>  http://hg.savannah.gnu.org/hgweb/octave/rev/b5e75ce299d8
> 
> jwe

Yes, the change I proposed did work for me.

Your changeset does as well.

Thanks,
Ben