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
and
/sw/local
Maybe they should be added to CMake by default.
>
> Andreas
>
Best regards,
-- andreas
--
http://www.cynapses.org/ - cybernetic synapses
signature.asc
Description: OpenPGP digital signature
_______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
