On Thu, Dec 12, 2013 at 11:46:24 -0500, Matthew Woehlke wrote:
> Actually... back up for a moment. Since we're talking about dynamic
> libraries here (none of this applies to static I think; in that case
> you must always relink), how would a non-ABI change in liba.so cause
> the result of linking
On 12/12/2013 11:46 AM, Matthew Woehlke wrote:
Where template.hpp changes (testing with 2.8.12.1 shows that touching
template.hpp triggers a rebuild with Ninja, but not Unix Makefiles),
That sounds like a bug :-).
Yes, this is a bug. ninja and make should be the same.
--
Powered by www.kitwa
On 2013-12-11 20:00, Ben Boeckel wrote:
On Wed, Dec 11, 2013 at 19:38:21 -0500, Matthew Woehlke wrote:
I don't think this is relevant? In these cases, a header is changing,
which will (hopefully) lead to the source files using that header
being rebuilt, which will cause the library to relink any
Ben Boeckel wrote:
> On Thu, Dec 12, 2013 at 00:00:42 +0100, Stephen Kelly wrote:
>> You opposed a sensible default for CMAKE_LINK_DEPENDS_NO_SHARED:
>>
>> https://www.mail-archive.com/cmake-developers@cmake.org/msg06169.html
>>
>> I continue to consider the default value of that to be a mistak
On 12/11/2013 6:00 PM, Stephen Kelly wrote:
You opposed a sensible default for CMAKE_LINK_DEPENDS_NO_SHARED:
https://www.mail-archive.com/cmake-developers@cmake.org/msg06169.html
I continue to consider the default value of that to be a mistake.
I am on the fence with this one. It is always b
On Wed, Dec 11, 2013 at 19:38:21 -0500, Matthew Woehlke wrote:
> I don't think this is relevant? In these cases, a header is changing,
> which will (hopefully) lead to the source files using that header
> being rebuilt, which will cause the library to relink anyway. (And if
> the sources *aren't* r
On 2013-12-11 19:21, Ben Boeckel wrote:
On Wed, Dec 11, 2013 at 17:13:00 -0500, Matthew Woehlke wrote:
Now, I *do* get that relinking is good if the library ABI changes.
However, that's not the case here, and I am wondering if it would be
possible for CMake to generate an additional, intermediar
On Wed, Dec 11, 2013 at 17:13:00 -0500, Matthew Woehlke wrote:
> Now, I *do* get that relinking is good if the library ABI changes.
> However, that's not the case here, and I am wondering if it would be
> possible for CMake to generate an additional, intermediary step after
> library linking to som
On 2013-12-11 17:13, Matthew Woehlke wrote:
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change in a "lower
level" library causes more than a hundre
On Wed, Dec 11, 2013 at 17:40:08 -0500, Bill Hoffman wrote:
> The other option sounds interesting but hard to implement in a cross
> platform manner.
Maybe an option to use this[1] tool would be useful?
--Ben
[1]http://ispras.linuxbase.org/index.php/ABI_compliance_checker
--
Powered by www.kitw
On Thu, Dec 12, 2013 at 00:00:42 +0100, Stephen Kelly wrote:
> You opposed a sensible default for CMAKE_LINK_DEPENDS_NO_SHARED:
>
> https://www.mail-archive.com/cmake-developers@cmake.org/msg06169.html
>
> I continue to consider the default value of that to be a mistake.
How would a relink be f
On 2013-12-11 17:40, Bill Hoffman wrote:
On 12/11/2013 5:13 PM, Matthew Woehlke wrote:
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change in a "lo
Matthew Woehlke wrote:
> I've been working on a project lately that isn't *that* massively large,
> but has an unusually high number of library and executable targets. One
> thing that's been bugging me is that any trivial change in a "lower
> level" library causes more than a hundred targets to b
On 12/11/2013 5:13 PM, Matthew Woehlke wrote:
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change in a "lower
level" library causes more than a hund
I've been working on a project lately that isn't *that* massively large,
but has an unusually high number of library and executable targets. One
thing that's been bugging me is that any trivial change in a "lower
level" library causes more than a hundred targets to be relinked, for no
good reas
15 matches
Mail list logo