John B wrote: > ---snip-- > >> When I ran cmake it said it found cairo, python, libxml2, etc... yet at the >> end it's looking for variables that are only set if the dev libraries are >> installed. With Craig's advice and with my experience and a little searching >> on the web I was able to find the solutions. But would it not make more >> sense to have the cmake script actually look for the dev libraries and >> output an error if it didn't find them? Then there would of been no question >> that that was the problem. This isn't a rant, just a suggestion to improve >> and make it easier for people like me that are generally spoiled by Mac and >> Windows installer applications ;-) >> > > That would make sense if all Linux distributions, BSD releases, and > Mac OS X all separated development headers from executables. As I > mentioned in response to another thread on this list, Slackware and > Slackware-based Linux distributions include development headers in > packages automatically. Maybe the RPM-based and Debian-based Linux > distributions can take a hint from Slackware and include the > development headers automatically instead of putting executables and > development headers into separate packages. > The separation is done for a reason, and it's quite useful. Sometimes a package with a relatively small binary can have truly huge headers. If a debug version of the library is also supplied it's even worse, and the development files for a package can be tens or hundreds of times the size of the runtime files. Tying the developer files and runtime files into a single package is rather limiting and IMO a clumsy workaround for problems in Linux package management systems.
What I'd like to see would be a way to ask a package management system "I have libfred get and install the -dev package. I don't care what it's called, you already know that". I'd also like to be able to trust that libfred would ALWAYS be packaged with the name "libfred" (or have an alias for that name) in every distro, so I could provide one set of instructions instead of ten or more. > FWIW, CMake is working as designed, in that it didn't find the headers > in the INCLUDE path until the development packages were installed. > > I do find the way it prompts the user in this case unfortunate and potentially confusing, though. It's another case where the CMake system shows that it's had absolutely no thought given to usability and user interface, even though it's technically excellent. The way the CMakeCache and ccmake work and the difficulty of writing CMake scripts that play well with ccmake and the cache but still respond to parameter/environment changes when re-run is another example of the lack of thought given to usability and interface. When I'm writing CMake scripts I try to make sure that I check required variables in my code and fail with a more informative error, so the user never gets CMake's default error about certain variables being unset. This means that the user can't then go in and set them with ccmake if they've just installed a hand-built copy somewhere weird, but must instead set the CMAKE_INCLUDE_PATH / CMAKE_LIBRARY_PATH to include the location of the files. I prefer it personally since it lets me better sanity-check everything, provide more useful error messages, and tie them in to the documentation better. -- Craig Ringer
