On 08/11/2010 04:02 PM, Eric Noulard wrote: > 2010/8/11 Alexander Neundorf <neund...@kde.org>: >> Well, I still think the UPPERCASE_ prefix also has it advantages, I don't >> have >> to remember the exact case of the module (was it FindLibXml2 or FindLibXML2 >> or Findlibxml2 or FindLibxml2, the variables are all just LIBXML_SOMETHING). >> It also makes them look more "consistent". > > The simplicity argument is a good one. > I was in favor of ExactCase because I found it more "coherent" > but I admit UPPERCASE is "easier to remember".
...but you need to remember the case anyway as the first argument to the find_package command: find_package(ExactCase) I think it is much more intuitive to keep using the same case after that. > So in the end I would say "I don't care" but let's do it for good: > > 1) Chose between UPPERCASE and ExactCase ExactCase > 2) Update FPHSA **and** Module/readme.txt accordingly Yes. FPHSA should provide both versions of the _FOUND variable to keep compatibility with outside projects using it. > 3) Review existing Modules and set-up "compatibility" missing vars > in them if needed. Provide and document ExactCase versions of *all* result variables from every module. The cache entry names used internally should remain unchanged. The ExactCase forms of the results should be provided and the UPPERCASE ones provided for compatibility where needed. > Checked <130> files, exact=63, allUp=55, mismatch=12 Good. There is more ExactCase precedent than we thought. -Brad _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
