Re: config-list.mk and obsoleted configurations

[Jeff Law <law@redhat.com>]

On 12/17/2015 11:58 AM, Jan-Benedict Glaw wrote:
> On Thu, 2015-12-17 11:39:24 -0700, Jeff Law <law@redhat.com> wrote:
>> On 12/17/2015 11:34 AM, Jan-Benedict Glaw wrote:
>>> On Thu, 2015-12-17 11:05:42 -0700, Jeff Law <law@redhat.com> wrote:
>>>> On 12/16/2015 03:46 AM, Jan-Benedict Glaw wrote:
>>>>> Shall I bisect one of the cases anew, with the "Test value of
>>>>> _GLIBCXX_USE_C99_WCHAR not whether it is defined" patch that
>>>>> uncovered it, applied? Starting with some arbitrary old revision?
>>>> Yes.  I'd really like to see config-list.mk working again.  The
>>>> first step is always building a test the developers can easily work
>>>> with.
>>>
>>> Will do. Have a good starting point?
>> The biggest problem is the breakage around wither USE_C99_WCHAR or delayed
>> folding.  I think I counted 30+ targets that were effected.
>
> It's probably delayed folding; seems the USE_C99_WCHAR stuff only
> uncovers it, doesn't it?
>
>> Once that's settled, I suspect anything remaining will be pretty minor.
>>
>> I'd disable interix completely.
>
> Seems to be not hard to fix. Breaks with:
I know, but it's not worth fixing IMHO.  Interix has been a dead product 
for a long time.  We almost got rid of it several years ago, but someone 
objected and said they'd maintain it.  I asked Trevor to put it back on 
the deprecated list a little while ago.

AFAICT it hasn't been building since 2012.  I fixed some of the problems 
a few months ago, but just can't really justify anyone's time to figure 
out which way to #define this away to preserve prior behaviour and to 
continue to keep it working over time.


>
>> Not sure what to do with avr-rtems at this point.
>
> My buildrobot just fails at the very same USE_C99_WCHAR issue right
> now. Is there something more hidden, later on in the build?
avr-rtems has deeper issues, which ultimately look like the same problem 
you're seeing with delayed folding, but aren't the same problem.

Essentially avr-rtems's definitions of various standard types are all 
conditional on flags with a default that is NULL.  Those are ultimately 
passed to one of the str* functions and GCC throws a warning/failure.

There's no way to fold those down to a constant, (or even to prove the 
NULL case couldn't happen IIRC).  So even once the current delayed 
folding issue gets fixed, avr-rtems will remain broken.

It's also unclear how long avr-rtems will be around.  I get the sense 
it's on its last legs -- and given we have both avr and rtems coverage 
via other targets, I don't think building avr-rtems is really all that 
helpful.

Jeff