I don't understand why gcc doesn't put frame_x86.inline.hpp into the generated/dependencies/frame.o.d file. Isn't the point of -MMD to calculate the full closer of header files used for listing as a dependency? Is this a bug in gcc or are we using it wrong?
I notice that Sun Studio compiler does put the arch-specific header file in the generated dependency file. Weird.
-- - Keith On 6/8/2012 11:58 AM, Volker Simonis wrote:
Hi, I've just stumbled across the problem that changing the implementation of an inline function in HotSpot does not necessarily rebuild all the call sites of that function. This is because because of the way how the build dependencies are handled within the HotSpot. As an example you may have a look at frame.cpp: frame.cpp includes frame.inline.hpp frame.inline.hpp includes frame_x86.inline.hpp However frame.cpp only depends on frame.inline.hpp directly (i.e. frame.cpp only includes frame.inline.hpp directly and this is where the dependencies generated by gcc with '-MMD' are computed from). So if an inline function in frame_x86.inline.hpp will be changed (e.g. the constructor frame::frame()), frame.cpp will not be recompiled in an incremental build, although it uses the constructor frame::frame(). This makes incremental builds useless (or dangerous, depending on the view point) when inline functions are changed. I think this is a non-trivial problem which is deeply rooted in the way how C++ implements inlining and the way how inline functions are defined in HotSpot (i.e. .hpp, .inline.hpp, _<cpu>.hpp and _<cpu>.inline.hpp files). I don't have a solution for it but just wanted to ask if somebody else already stumbled upon this problem and/or has solution for it? Regards, Volker
