kdeexamples buildsystem

[Alexander Neundorf]

Hi Mike,

On Thursday 14 July 2011, Michael Jansen wrote:
> Hi
> 
> I just had a look at the HowToInstallALibrary example and have some
> questions.

thanks for having a look over the stuff.
 
> 1. Why on earth does the example introduce LIB_INSTALL_DIR_SUFFIX instead
> of LIB_SUFFIX. I am fighting quite a uphill battle in non kde projects to
> consider LIB_SUFFIX the standard and to just use it for the least surprise
> of a user?

I don't have a strong opinion on this.
I named it "LIB_INSTALL_DIR_SUFFIX" here because it is more explicit about the 
meaning, and to show that you can actually name it in your project as you want 
to, i.e. this is not something given by cmake.

If you think it is more important to try to push for LIB_SUFFIX as "standard", 
that's also ok with.
Feel free to change that in the example.

> 2. I know the cmake documentation is quite ... Just have a look at the file
> readme.txt from the Modules/ directory and compare especially the
> recommendations about "This should (not) be a cache entry)" to the reality.
> But the cmake documentation says: from find_package
> 
> >       Config mode provides an elaborate interface and search procedure.
> >       Much of the interface is provided for completeness and for use
> >       internally by find-modules loaded by Module mode.
> 
> And here we go and ignore that. Are we sure this is the right thing to do?


For the installed library "bar" one cache entry "Bar_DIR" is created. That's 
how the config-mode works.
Please explain what you mean with we ignore something.
 
> 3. And then there is the problem that the config mode looks there:
> > CMake constructs a set of possible installation prefixes for the package.
> > Under each prefix several directories are searched for a configuration
> > file. The tables below show the directories searched. Each entry is meant
> > for installation trees following Windows (W), UNIX (U), or Apple (A)
> > conventions.
> > 
> > <prefix>/                                                 (W)
> > 
> >   <prefix>/(cmake|CMake)/                                 (W)
> >   <prefix>/<name>*/                                       (W)
> >   <prefix>/<name>*/(cmake|CMake)/                         (W)
> >   <prefix>/(share|lib)/cmake/<name>*/                     (U)
> >   <prefix>/(share|lib)/<name>*/                           (U)
> >   <prefix>/(share|lib)/<name>*/(cmake|CMake)/             (U)
> 
> What it does not tell is that it looks into lib64 too. Or else we would not
> find anything on opensuse. But you can't influence that. In a find module i
> at least could look only into the correct directories. But cmake has
> anyway poor support for systems with both 32 and 64bit devel packages. 

Please explain which problem or issue you see here.

> The best is to use pkgconfig ... then it works best.

I completely disagree with this one.
CMake can find everything, and I consider it a hassle to have to setup 
additionally to cmake, i.e. CMAKE_PREFIX_PATH also PKGCONFIG_PATH (or what the 
name was), since it is unnecessary, cmake can do that.
Beside that. the config-files from cmake are much more powerful, they provide 
more information, they provide the information not tailored for the command 
line syntax of a specific compiler, they work fine also under Windows, they 
support multiple build configurations under Windows.

Alex