[7/9] Rewrite lookup_static_symbol to use gdbarch routine

  Doug Evans <xdje42@gmail.com> writes:
> On Thu, Nov 13, 2014 at 4:52 AM, Yao Qi <yao@codesourcery.com> wrote:
>> Doug Evans <xdje42@gmail.com> writes:
>>
>> Hi Doug,
>> Sorry for the delayed response.
>>
>>> 2014-11-08  Doug Evans  <xdje42@gmail.com>
>>>
>>>       PR symtab/17564
>>>       * gdb.base/symtab-search-order.exp: New file.
>>>       * gdb.base/symtab-search-order.c: New file.
>>>       * gdb.base/symtab-search-order-1.c: New file.
>>>       * gdb.base/symtab-search-order-shlib-1.c: New file.
>>
>> These new .c files need copyright headers.
>
> These files are so trivial, I left them out.
> [The .exp file *does* have a copyright header.]
>
> I know the contribution checklist page mentions always adding them,
> even if the GNU standards only require them for legally significant
> headers.
> It's not clear that that is intended to apply in particular cases such as these.
>
> [I can add them, but establishing some clarity would be nice.]

Hi.
To keep things moving along I added the copyright headers.

However, I think we could be a bit more lax when it comes to
such trivial testcases.

GCC isn't this pedantic about it.
  

Hi Doug,

> To keep things moving along I added the copyright headers.

Thanks for doing that.

> However, I think we could be a bit more lax when it comes to
> such trivial testcases.

The FSF allows us to be lax for trivial files (with 10 lines being
one explicit limit on triviality).  But:

The problem with being lax is that it creates a little extra work
for us at the start of each year, when we update the copyright headers.
The FSF has been asking us to look into copyright headers in the past,
and it was a lot of work, so I've added a bit of simple-minded code
to the script that updates the copyright headers in GDB to also issue
a warning if a copyright header hasn't been found. That way, we can
then investigate the few problematic files each year rather than
a massive number when the FSF notices something.

That's why I always appreciate the copyright headers being added
right from the start.

So, again, thanks a lot for adding those! :)
  

On Sat, Nov 15, 2014 at 7:22 PM, Joel Brobecker <brobecker@adacore.com> wrote:
> Hi Doug,
>
>> To keep things moving along I added the copyright headers.
>
> Thanks for doing that.
>
>> However, I think we could be a bit more lax when it comes to
>> such trivial testcases.
>
> The FSF allows us to be lax for trivial files (with 10 lines being
> one explicit limit on triviality).  But:
>
> The problem with being lax is that it creates a little extra work
> for us at the start of each year, when we update the copyright headers.
> The FSF has been asking us to look into copyright headers in the past,
> and it was a lot of work, so I've added a bit of simple-minded code
> to the script that updates the copyright headers in GDB to also issue
> a warning if a copyright header hasn't been found. That way, we can
> then investigate the few problematic files each year rather than
> a massive number when the FSF notices something.
>
> That's why I always appreciate the copyright headers being added
> right from the start.
>
> So, again, thanks a lot for adding those! :)

No worries.
A few more words added to the wiki to added the needed context and
clarity would be great.
I'll do that.
  

On Sun, Nov 16, 2014 at 1:53 PM, Doug Evans <xdje42@gmail.com> wrote:
> On Sat, Nov 15, 2014 at 7:22 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> Hi Doug,
>>
>>> To keep things moving along I added the copyright headers.
>>
>> Thanks for doing that.
>>
>>> However, I think we could be a bit more lax when it comes to
>>> such trivial testcases.
>>
>> The FSF allows us to be lax for trivial files (with 10 lines being
>> one explicit limit on triviality).  But:
>>
>> The problem with being lax is that it creates a little extra work
>> for us at the start of each year, when we update the copyright headers.
>> The FSF has been asking us to look into copyright headers in the past,
>> and it was a lot of work, so I've added a bit of simple-minded code
>> to the script that updates the copyright headers in GDB to also issue
>> a warning if a copyright header hasn't been found. That way, we can
>> then investigate the few problematic files each year rather than
>> a massive number when the FSF notices something.
>>
>> That's why I always appreciate the copyright headers being added
>> right from the start.
>>
>> So, again, thanks a lot for adding those! :)
>
> No worries.
> A few more words added to the wiki to added the needed context and
> clarity would be great.
> I'll do that.

Hmmm, I see that in gdb the convention is "Copyright (C)" whereas in
the gdb/testsuite the convention is "Copyright" with no "(C)".
Some tests have "(C)" but the vast majority don't.
Both are allowed, and I'm not planning on going through and changing anything.
Just thought I'd point it out.
  

> Hmmm, I see that in gdb the convention is "Copyright (C)" whereas in
> the gdb/testsuite the convention is "Copyright" with no "(C)".
> Some tests have "(C)" but the vast majority don't.
> Both are allowed, and I'm not planning on going through and changing anything.
> Just thought I'd point it out.

Yeah :-( - I think the prefered form is with the (C), and I wish that
it was automatically added during the copyright year update. But,
of course, this is not possible without the script having knowledge
of the file type because it's different for files such as texi files,
for instance. I might write a one-off python script specifically for
that specific purpose, someday....