Re: build fails due to 'lib/assert.h' on mac os x

[Jim Meyering]

On Fri, Sep 9, 2016 at 3:51 PM, Jim Meyering <address@hidden> wrote:
> On Fri, Sep 9, 2016 at 1:47 PM, Jim Meyering <address@hidden> wrote:
>> On Fri, Sep 9, 2016 at 1:29 PM, Jim Meyering <address@hidden> wrote:
>>> On Thu, Sep 8, 2016 at 7:33 PM, Assaf Gordon <address@hidden> wrote:
>>>> On 09/08/2016 04:40 PM, Jim Meyering wrote:
>>>>>
>>>>> On Wed, Sep 7, 2016 at 10:17 PM, Assaf Gordon <address@hidden>
>>>>> wrote:
>>>>>>
>>>>>>  $ make
>>>>>>  [...]
>>>>>>   make[2]: *** No rule to make target `lib/assert.h', needed by `all'.
>>>>>> Stop.
>>>>
>>>>
>>>>> I noticed the same failure on a Centos 7 system.
>>>>> I dug enough to find the probable cause+solution in the attached proposed
>>>>> patch:
>>>>
>>>>
>>>> Thanks!
>>>>
>>>> That fixed the build on Mac OS X.
>>>
>>> Thanks for checking.
>>> I was not satisfied with my knee-jerk fix, since I hadn't really
>>> understood the failure, ... so backed out my change locally on each
>>> system (centos and osx) and tried to reproduce, but now cannot
>>> reproduce it, anywhere. I even tried in a just-cloned repository.
>>>
>>> Assaf, would you please try to reproduce that failure in a just-cloned
>>> working directory?
>>
>> Actually, I've just reproduced it again, so I should be able to deal with it.
>
> The real problem is that the getprogname module is using the assert-h
> module unnecessarily. That module is required only for C11-conformant
> static_assert, not for mere <assert.h>.
> Here's the patch for that (in gnulib) that I will push soon:
>
> P.S., There is still the issue that one should be able to use the
> assert-h module only from a gnulib-test in a partially non-recursive
> project like coreutils, but I will not pursue that one right now.

I've pushed that to gnulib and pushed this gnulib-submodule-updating
commit to coreutils to fix the build failure there:

cu-getprogname-update.diff
Description: Text document