(0038013)
Stephen Kelly (developer)
2015-02-21 04:02

In my view, the problem you're hitting is the outcome of

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6103 [^]

It didn't go my way :). If it did there would be no problem.

I object to changing find_dependency to look for UPPERCASE_FOUND. As it is, find_dependency incentivises consistency for the _FOUND variable. I don't want to change that.

So the modules affected by this have to be changed as described by Brad (he wanted to incentivise changing the modules to set the _FOUND variable explicitly):

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6103/focus=6143 [^]

Which modules are affected by this?

(0038016)
Kiron (reporter)
2015-02-23 03:12

> Which modules are affected by this?

Problem was with a custom self written FindModule which uses FPHSA
but did not set the FOUND_VAR explicitly.

It is a bit annoying that two standard CMake modules disagree by default on how to name the Module_FOUND variable.

(0038021)
Brad King (manager)
2015-02-23 09:30

Re 0015412:0038013: There was another discussion long before that one where I wanted ExactCase_FOUND to be the standard for FPHSA but was outvoted because so many of the existing modules already used UPPERCASE_FOUND. If that had gone my way then everything would be consistent now.

After seeing how this comes up for third-party modules I've reconsidered my position from two years ago in the thread you linked. I think we should go ahead with the behavior you originally proposed there, at least when no explicit FOUND_VAR option is passed.

(0038041)
Stephen Kelly (developer)
2015-02-23 16:47

Good, let's finally fix this problem :)

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6cb72e0 [^]
FPHSA: Always populate the ExactCase_FOUND variable (0015412).

(0038047)
Brad King (manager)
2015-02-24 08:37

Re 0015412:0038041: The FOUND_VAR option should still be checked/enforced to only allow the two possible names if it is given.

(0038058)
Stephen Kelly (developer)
2015-02-24 14:00

Given that the FOUND_VAR is ignored and has no semantics, I don't think that is necessary.

Do you feel strongly about that?

(0038059)
Brad King (manager)
2015-02-24 14:07

Re 0015412:0038058: If the argument is accepted then it should be validated when used, as before. By deprecating it we shouldn't allow more uses than before.

(0038176)
Alex Neundorf (developer)
2015-03-07 14:03

Stephen, if you know what to do go ahead and do it.

(0038177)
Stephen Kelly (developer)
2015-03-08 11:33

Ok, sorry! :)

(0038203)
Brad King (manager)
2015-03-11 15:52

Steve, the change linked in 0015412:0038041 never made it to 'master' due to my comment in 0015412:0038047. Please revise and restore the topic when ready.

(0038526)
Brad King (manager)
2015-04-15 14:45
edited on: 2015-04-17 10:49

I've revised the change from 0015412:0038041 to maintain the FOUND_VAR argument validation. Applied:

FPHSA: Always populate the ExactCase_FOUND variable
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1a6d15b [^]

(0039779)
Robert Maynard (manager)
2015-11-02 09:13

Closing resolved issues that have not been updated in more than 4 months.

Issue History
Date Modified	Username	Field	Change
2015-02-20 07:53	Kiron	New Issue
2015-02-20 10:40	Brad King	Assigned To	=> Stephen Kelly
2015-02-20 10:40	Brad King	Status	new => assigned
2015-02-20 10:40	Brad King	Target Version	=> CMake 3.3
2015-02-21 04:02	Stephen Kelly	Note Added: 0038013
2015-02-23 03:12	Kiron	Note Added: 0038016
2015-02-23 09:24	Brad King	Target Version	CMake 3.3 =>
2015-02-23 09:30	Brad King	Note Added: 0038021
2015-02-23 16:47	Stephen Kelly	Note Added: 0038041
2015-02-24 08:37	Brad King	Note Added: 0038047
2015-02-24 14:00	Stephen Kelly	Note Added: 0038058
2015-02-24 14:07	Brad King	Note Added: 0038059
2015-03-05 10:01	Brad King	Target Version	=> CMake 3.3
2015-03-07 07:00	Stephen Kelly	Assigned To	Stephen Kelly => Alex Neundorf
2015-03-07 07:01	Stephen Kelly	Summary	find_dependency macro does not check for <UPPERCASED_NAME>_FOUND => FPHSA should set ExactCase_FOUND variable
2015-03-07 14:03	Alex Neundorf	Note Added: 0038176
2015-03-07 14:03	Alex Neundorf	Assigned To	Alex Neundorf => Stephen Kelly
2015-03-08 11:33	Stephen Kelly	Assigned To	Stephen Kelly =>
2015-03-08 11:33	Stephen Kelly	Note Added: 0038177
2015-03-11 15:52	Brad King	Note Added: 0038203
2015-04-15 14:45	Brad King	Note Added: 0038526
2015-04-15 14:45	Brad King	Status	assigned => resolved
2015-04-15 14:45	Brad King	Resolution	open => fixed
2015-04-15 14:45	Brad King	Fixed in Version	=> CMake 3.3
2015-04-17 10:49	Brad King	Note Edited: 0038526
2015-11-02 09:13	Robert Maynard	Note Added: 0039779
2015-11-02 09:13	Robert Maynard	Status	resolved => closed
2016-03-22 10:29	Stephen Kelly	Relationship added	has duplicate 0016028

Notes
(0038013) Stephen Kelly (developer) 2015-02-21 04:02	In my view, the problem you're hitting is the outcome of http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6103 [^] It didn't go my way :). If it did there would be no problem. I object to changing find_dependency to look for UPPERCASE_FOUND. As it is, find_dependency incentivises consistency for the _FOUND variable. I don't want to change that. So the modules affected by this have to be changed as described by Brad (he wanted to incentivise changing the modules to set the _FOUND variable explicitly): http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6103/focus=6143 [^] Which modules are affected by this?

(0038016) Kiron (reporter) 2015-02-23 03:12	> Which modules are affected by this? Problem was with a custom self written FindModule which uses FPHSA but did not set the FOUND_VAR explicitly. It is a bit annoying that two standard CMake modules disagree by default on how to name the Module_FOUND variable.

(0038021) Brad King (manager) 2015-02-23 09:30	Re 0015412:0038013: There was another discussion long before that one where I wanted ExactCase_FOUND to be the standard for FPHSA but was outvoted because so many of the existing modules already used UPPERCASE_FOUND. If that had gone my way then everything would be consistent now. After seeing how this comes up for third-party modules I've reconsidered my position from two years ago in the thread you linked. I think we should go ahead with the behavior you originally proposed there, at least when no explicit FOUND_VAR option is passed.

(0038041) Stephen Kelly (developer) 2015-02-23 16:47	Good, let's finally fix this problem :) http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f6cb72e0 [^] FPHSA: Always populate the ExactCase_FOUND variable (0015412).

(0038047) Brad King (manager) 2015-02-24 08:37	Re 0015412:0038041: The FOUND_VAR option should still be checked/enforced to only allow the two possible names if it is given.

(0038058) Stephen Kelly (developer) 2015-02-24 14:00	Given that the FOUND_VAR is ignored and has no semantics, I don't think that is necessary. Do you feel strongly about that?

(0038059) Brad King (manager) 2015-02-24 14:07	Re 0015412:0038058: If the argument is accepted then it should be validated when used, as before. By deprecating it we shouldn't allow more uses than before.

(0038176) Alex Neundorf (developer) 2015-03-07 14:03	Stephen, if you know what to do go ahead and do it.

(0038177) Stephen Kelly (developer) 2015-03-08 11:33	Ok, sorry! :)

(0038203) Brad King (manager) 2015-03-11 15:52	Steve, the change linked in 0015412:0038041 never made it to 'master' due to my comment in 0015412:0038047. Please revise and restore the topic when ready.

(0038526) Brad King (manager) 2015-04-15 14:45 edited on: 2015-04-17 10:49	I've revised the change from 0015412:0038041 to maintain the FOUND_VAR argument validation. Applied: FPHSA: Always populate the ExactCase_FOUND variable http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d1a6d15b [^]

(0039779) Robert Maynard (manager) 2015-11-02 09:13	Closing resolved issues that have not been updated in more than 4 months.