Re: [PATCH v2 0/6] Move gdbsupport to top level

[Pedro Alves <palves@redhat.com>]

On 1/15/20 9:46 PM, Pedro Alves wrote:
> On 1/15/20 9:35 PM, Pedro Alves wrote:
>> On 1/15/20 8:23 PM, Pedro Alves wrote:
>>> On 1/15/20 2:55 PM, Pedro Alves wrote:
>>>> On 1/15/20 2:41 PM, Pedro Alves wrote:
>>>>> Don't know what I think of gnulib headers including <config.h>.
>>>>> Maybe we should rename gdb's config.h to gdb-config.h too.
>>>>
>>>> Hit reply to soon.  I meant to add,
>>>>
>>>> ... and then, add a manually-written config.h in the build
>>>> dir that does:
>>>>
>>>>  #include <gdbsupport/support-config.h>
>>>>  #include <gdb-config.h>
>>>>
>>>> We'd do the same to gdbsupport, add a config.h in its
>>>> build dir that does:
>>>>
>>>>  #include "gnulib/config.h"
>>>>  #include <support-config.h>
>>>>
>>>> Those config.h files would go in the build dirs so that
>>>> they're not picked by other build directories.
>>>>
>>>> With that, any "#include <config.h>" in any header ends up
>>>> picking the currently-being-built project's config.h, plus
>>>> the dependencies' config.h files.
>>>>
>>>> Just a half-baked thought.  Not sure it's the best idea.
>>>
>>> I tried it and it seems to work OK.  Fixes the build at least.
>>> Still not sure it's the best idea.  WDYT?
>>>
>>> The patch is actually quite small, but since I've rename
>>> config.h -> gdb-config.h etc., and _then_ added new config.h
>>> files, git doesn't notice the renames.
>>>
>>> I wonder whether there's anything could do to stop gnulib and
>>> gdbsupport's configure from defining PACKAGE_NAME etc. in their
>>> generated config.h files.
>>>
>> Here's an improved version, which fixes gdbserver's standalone
>> build, simplifies gdbsupport's config.h (there's no need for
>> #ifdef GDBSERVER stuff since gdbserver doesn't use gdbsupport 
>> as a library yet), and adds copyright/intro comments.
>>
> 
> I put this in users/palves/config.h if you want to play with it.

I've also pushed a patch there to fix the missing -std=gnu++11 issue.

Thanks,
Pedro Alves