[Scribus] 1.3.5svn compile error on Ubuntu Gutsy
Sun Feb 17 04:52:59 CET 2008
John B wrote:
>> 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.
More information about the scribus