pkg_config quick non intrusive solution

[Helio Chissini de Castro]

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
>
> > 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. 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, 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.


> > 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

>> 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

>> 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.

>> 3.) then improve the modules you are interested by sending the patch first 
to kde-buildsystem
Yep, ok

> Don't want to blame anyone, but FindQCA2 was also broken, QCA2_INCLUDE_DIR
> wasn't set anymore under unix using pkg-config. I've fixed that by setting
> it to QCA2_INCLUDEDIR, which is set by the pkg-config stuff.
I created a monster, started the modifications and others followed my changes. 
In a matter of fact, the error change was good, because there other persons 
with qca2 find issues way before those changes and almost never report that not 
works.

I will add in wiki a porting module HOWTO


-- 
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20081114/29b0f54e/attachment.sig