When you add to them you are often adding some larger feature which would have
required a rebuild anyway, and they go long times with no change... I have
never found the rebuild required when these files are touched to be a drag on
my productivity. And I really appreciate their convenience.
B
The dependency edges caused by the file means that any time anyone
touches that file everything that depends on it is rebuilt. The way
it's included basically means you're doing a full build any time you
touch it. It's who is depending on this file or any file this file
includes, not the other way
> On May 15, 2019, at 3:13 PM, Jim Ingham wrote:
>
> This is a common header file that specifies either common enums & #defines in
> lldb, or forward declarations of the common classes in lldb. They don't
> depend on any other header files in the system, they just establish the
> common nam
This is a common header file that specifies either common enums & #defines in
lldb, or forward declarations of the common classes in lldb. They don't depend
on any other header files in the system, they just establish the common names
you should use. So the dependency analysis introduced by th
A couple of perspectives FWIW:
a) Header file includes increase overall dependencies which affects
incremental rebuild time whenever you touch something. Especially more
when that header is included into multiple headers that are then
included into an array of translation units
b) Having each file
This commit makes things look a little cleaner, but do we need any of these
forward declarations at all?
Most of these files either directly include lldb-forward.h or get it from
lldb-types.h or lldb-defines.h (which includes lldb-types.h). As a general
practice we've been getting all the ll
On Tue, 14 May 2019 13:38:57 +0200, Florian Weimer via lldb-dev wrote:
> The target process has loaded libpthread.so.0, so it's not the usual
> problem of libthread_db not working without libpthread.
>
> On the other hand, I realize now that the lldb command cannot access TLS
> variables, either.
