[CMake] Find*.cmake variable naming

Alexander Neundorf a.neundorf-work at gmx.net
Fri Jan 18 16:39:17 EST 2008


On Friday 18 January 2008, Andreas Schneider wrote:
> Andreas Pakulat wrote:
> > On 17.01.08 23:41:54, Andreas Schneider wrote:
> >> Andreas Pakulat wrote:
> >>> On 14.01.08 23:40:39, Andreas Schneider wrote:
> >>>> Rodolfo Schulz de Lima wrote:
> >>>>> Hi, I'd like to comment on the Find*.cmake variable naming procedure
> >>>>> adopted by cmake. Right now I have to look at some Find*.cmake files
> >>>>> to see what are the output variables they create. Some packages
> >>>>> create a *_LIBRARY, others *_LIBRARIES, others *_INCLUDE_DIRS and
> >>>>> others *_INCLUDE_DIR. The Modules/readme.txt procedure isn't being
> >>>>> used for some packages.
> >>>>>
> >>>>> Also the vast majority creates upcased (is this an adjective?)
> >>>>> variable names, BUT Boost and wxWidgets. There two define
> >>>>> Boost_FOUND, Boost_LIBRARIES, wxWidgets_FOUND, wxWidgets_LIBRARIES.
> >>>>> It should be better if they were BOOST_FOUND, WXWIDGETS_FOUND etc.
> >>>>
> >>>> For much better FindBoost.cmake module take a look at
> >>>
> >>> I've just reported a bug for CMake with an updated/combined version of
> >>> that FindBoost and the one from Mike Jackson.
> >>
> >> I've looked at your module. The variable names should be all uppercase.
> >
> > No, please read the readme.txt in the modules directory of cmake. The
> > first part of the variable should follow the naming style of the
> > FindXX.cmake file.
>
> Hi Andreas,
>
> hmm ok, I don't like uppercase and lowercase mixed in the variable name. It
> should be just one, lower or upper.
>
> FindQt4.cmake uses uppercase for all variables.
>
> >> I don't think it is a good idea that you *have to define the boost
> >> version*. There should be the possibility to define the version but the
> >> module should find it, this is what the module is for. If you write
> >> Modules always think about user and packagers.
> >
> > Uhm, the problem is that there's no way to find the libraries without
> > the version number because unfortunately boost puts its version number
> > into the library filenames (and some other stuff).
>
> There is a way. Normally on Linux if you install the devel package you have
> libfoo.so which is a symbolic link to the full so name.
>
> > And hardcoding the version numbers into the FindXX.cmake modules is
> > really bad as that one is much harder to change (without forking) than
> > the CMakeLists.txt in your project.
>
> I don't say that hardcoding them into the FindXXX.cmake is the way to go
> but that you always have to define it is the same problem. If you don't
> provide a version number then the module should try to find it.
>
> > However I agree that the FindXXX.cmake module needs to be able to
> > support a range of version numbers at the same time. So the user can
> > specify a list of versions to try.
>
> Yep, see above.
>
> >> Your version doesn't find any library on openSUSE
> >
> > Thats an opensuse bug - IMHO, they patched the boost buildsystem or
> > renamed the files after building to get at this.
> >
> > Anyway, adding support for not having any suffix is not a big deal :)
>
> Could you please add it. A CMakeLists.txt for testing would be nice too.
> Maybe we should start to provide some macros for easy testing of
> FindXXX.cmake modules.
>
> >> The search paths for macports and fink are missing.
> >
> > Where do those put their stuff? Note that /usr/lib and /usr/local/lib
> > are already being searched due to the removal of the NO_DEFAULT_PATHS. a
>
> It is
>
> /opt/local

This one is already, at least cmake cvs.

> and
>
> /sw/local

/sw is added for the Mac (without /local).

Alex


More information about the CMake mailing list