Brad King wrote:
On 2/25/2013 5:18 PM, Matthew Woehlke wrote:
The possibility that first came to mind is where the API depends on
compiler flags or similar preprocessor-ish bits, especially if these are
not well guarded with something like a configured config.h to change
when these change
On 02/24/2013 10:29 AM, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default.
For reference, it was introduced in this thread:
Brad King wrote:
If the option were to be on by default then instead there
should be the reverse option off by default with a name like:
CMAKE_LINK_DEPENDS_SHARED_LIBRARIES
I implemented that but one of the dashboards already fails:
On 02/25/2013 11:46 AM, Stephen Kelly wrote:
Brad King wrote:
If the option were to be on by default then instead there
should be the reverse option off by default with a name like:
CMAKE_LINK_DEPENDS_SHARED_LIBRARIES
I implemented that but one of the dashboards already fails:
On 02/25/2013 01:29 PM, Matthew Woehlke wrote:
On 2013-02-24 10:29, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default. Is there any reason not
to enable it by default?
What is the use case for this?
On Monday 25 February 2013, Brad King wrote:
On 02/24/2013 10:29 AM, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default.
For reference, it was introduced in this thread:
On 02/25/2013 02:18 PM, Alexander Neundorf wrote:
It is a change in default behavior.
Maybe with a policy ?
How would it trigger? We can't warn on every target that links
to a shared library. We're not changing any existing interfaces.
The behavior only affects the dependencies placed in
On Monday 25 February 2013, Brad King wrote:
On 02/25/2013 02:18 PM, Alexander Neundorf wrote:
It is a change in default behavior.
Maybe with a policy ?
How would it trigger? We can't warn on every target that links
to a shared library. We're not changing any existing interfaces.
if
On 2013-02-25 14:00, Brad King wrote:
On 02/25/2013 01:29 PM, Matthew Woehlke wrote:
On 2013-02-24 10:29, Stephen Kelly wrote:
CMAKE_LINK_DEPENDS_NO_SHARED was introduced in this cycle, but off by
default. It seems useful enough to be on by default. Is there any reason not
to enable it by
On 02/25/2013 02:56 PM, Matthew Woehlke wrote:
I guess my personal opinion is that I can think of enough theoretical
ways where a relink might be needed, and haven't encountered a project
where the relink cost is sufficiently high, to feel that I would
personally want to not relink.
You've
On 2013-02-25 15:02, Brad King wrote:
Can you elaborate on some of the theoretical cases where relinking
will be needed but no header files have changed? It would be useful
to have them available for discussion.
The possibility that first came to mind is where the API depends on
compiler
Brad King wrote:
On 02/25/2013 03:09 PM, dlrd...@aol.com wrote:
Can you elaborate on some of the theoretical cases where relinking
will be needed but no header files have changed? It would be useful
to have them available for discussion.
I can think of one, but it’s probably not that
On 2/25/2013 5:18 PM, Matthew Woehlke wrote:
The possibility that first came to mind is where the API depends on
compiler flags or similar preprocessor-ish bits, especially if these are
not well guarded with something like a configured config.h to change
when these change (and ensure that
13 matches
Mail list logo
