pkg_config quick non intrusive solution

[Alexander Neundorf]

On Friday 14 November 2008, Helio Chissini de Castro wrote:
> On Quinta 13 Novembro 2008, Andreas Pakulat wrote:
> > > But (a big but), I had a look at the modules you modified, the diff
> > > compared to the versions before is attached.
> > >
> > > There are _major_ problems:
>
> Yes, *now* i know since we discover reason

So if you are doing bigger changes on code which is not yours and where you 
don't feel expert enough, please synchronize with the maintainer before.

> > > FindExiv2.cmake: completely broken on Windows
> > > FindKexiv2, FindKipi: broken if pkgconfig was found but failed (the
> > > same problem with find_path() as in FindStrigi yesterday), source- and
> > > styleguide-incompatible renaming of the include dir variable
>
> I will fix as soon i have windows install in my machine
>
> > > FindXine: completely broken, relies on pkgconfig under !Windows, under
> > > Windows does nothing, documentation removed, source- and styleguide
> > > incompatible renames
>
> FindXine is older, comes from Phonon ( more than 2 months already ) and i
> just copy from there. Ii will track down all pkgconfig modules
>
> > 2) Even if they wouldn't obviously break things, they are too big and too
>
> many changes at once. I don't feel I can even kind-of guarantee that they
> still work as good as before.
>
> > 3) what is actually the motivation for these changes ?
>
> My motivation is clean out the legacy. 

What exactly is "legacy" here for you ?

> I was planning such change since
> some time ago, but waited the official move to requires cmake 2.6.2.
> One of the issues of being such a large project of KDE is the fact that we
> hardly can keep track of everything, and more if you are a buildsystem or a
> release team guy.  As a packager, i fall down in the past too much old
> things from auto*tools that remains from kde 1, 2 inside kde3 and every new
> auto* update, sometimes we need regenerate everything, and barely can
> guarantee the results
> So, after 2.6, the OLD pkgconfig macro is issuing a warning, 

It did already before.

> and would be
> fine if we keep that and not touch if we have sure that cmake will never
> remove that. And i won't dare to force a copy on kde cmake just because we
> need keep old.
> And worst, new modules would be always written with new macro, and will
> fall in our issue of fullpath
> So, even keeping old-but-work-with-warnings macro, new modules would break.
> Be immediately, be that the right moment we have a new devel.
> So, i was accepting all the backfire too since i'm taking role to do that
> changes and accept peoples blame, but i consider a small curve and
> necessity to understand what need to do to keep our build safe in the next
> future years.

I understand all that, but:
if you plan bigger changes on the buildsystem, announce on kde-buildsystem 
first.

About the old UsePkgConfig.cmake: I'm happy if you remove it. Laurent did that 
for some files (with only few problems). You didn't replace the deprecated 
UsePkgConfig.cmake with the new FindPkgConfig.cmake, instead you *rewrote* 
all these modules completely, resulting in the basically to-be-expected 
breakage.

> > > FindStrigi: seems to work (but nevertheless has more modifications than
> > > I feel comfortable with)
>
> Strigi was the first one to address the issue of fullpath. Changes are
> really needed considering that, Even if i not touch it, We had
> inconsistency that places are using STRIGI_LIBRARIES and other using the
> find forced other libs. Again was another case that people added thing on
> module to fix their build instead of do the right thing fixing the module.
> This module will need to be changed again after we have a new PkgConfig as
> mentioned with the fullpath

Strigi (and all other packages built with cmake) should install a 
FooConfig.cmake file which we can load from cmake, this way we don't need 
pkgconfig at all anymore.
We didn't do it yet because we require 2.6.2 since just a week and we have to 
check with the kdesupport maintainers which version of cmake they want to 
support.

> >> 1.) ASAP revert the files completely back to the state they were before
> >> your changes
>
> In a better way, i'm installing a vm with windows and will test again.
> Then i will fix all modules

It is broken right now, no time to wait.
I'll revert now and then we can start improving them one by one.

> >> 2.) then enhance FindPkgConfig.cmake module as you suggested
>
> Yes, same way
> Btw, we are using fullpath, but FindKDE4Internal still is setting policy
> CMP0003 as OLD, which means there places that uses non full path and is ok.
> Can we plan a taskforce changing the policy on day to change every place
> after trunk been not 4.2 any more ? I'm ok in do that by myself, as i'm
> have resources to build everything at office.

I think so. But let's wait with that decision until 4.2 is out.

...
> I created a monster, started the modifications and others followed my
> changes. 

No, no monster in sight. You broke stuff. Others (you mean Laurent, right ?) 
also replaced UsePkgConfig, but did only that, instead of rewriting the 
modules completely.

> I will add in wiki a porting module HOWTO

Which "module porting" do you mean ?

Alex