[Scribus] 1.3.5svn compile error on Ubuntu Gutsy

[Craig Ringer]

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