[Kde-perl] Qt Compile Flags (Was: Compiling Without Installing)

[Jonathan Yu]

Chris:

Hm.

I suppose that the entire directory tree should be kept as-is, since
having CMake build everything is what other bindings do (previous to
this message I was unaware of that design consideration).

On the other hand, the other stuff isn't really all that important
from a Perl standpoint.

What I want to do, then, is push just the perl folder itself as its
own distribution to CPAN. Then nothing in our repository needs to be
moved. (Some minor adjustments may need to be made, but overall the
package structure should be mostly intact)

I'll work over the next couple days with getting the Makefile.PL to
detect if smoke is installed and die otherwise (since this is
something CMake takes care of, right?). Then it can be uploaded to
CPAN as-is. I'm currently looking into extending App::Info to help us
find Qt stuff (see App::Info on CPAN).

Oh, one thing I'd like to get your opinion on, though: do you mind if
I upgrade the build over to Build.PL? What impact does that have on
our package, and on how CMake builds it? I imagine it'd just be a
simple change: perl Build.PL; perl Build test (rather than perl
Makefile.PL; make). However, since it would be using 'perl Build'
rather than make, I'm not sure how it'd integrate with CMake; probably
not as nicely.

The reason I want to switch it over is because Build.PL is much more
capable of handling complex tasks than Makefile.PL. Things like
recommended dependencies, and in general the syntax is just more
maintainable to me. I could arrange for a compatibility Makefile.PL to
be available too (using Module::Build::Compat).

Cheers,

Jonathan

On Wed, Jun 3, 2009 at 3:43 PM, Chris Burel <chrisburel at gmail.com> wrote:
> Yes, pkg-config will work for us for Qt, but not for Smoke.  Last time
> I looked, kde-bindings doesn't ship with .pc files.  I checked
> <kdeprefix>/lib/pkgconfig, and saw none related to smoke.  Perhaps
> that'd be useful for smoke to include?
>
> Jonathan, I saw a post from you earlier about restructuring the
> directory layout of the bindings to accommodate using the
> Makefile.PL/ExtUtils::MakeMaker build method.  Currently we have this
> PerlQt4
>  |-smoke
>  |  \-qt
>  |    \-...
>  \-perl
>    \-bindings files
>
> You wanted to make it
> PerlQt4
>  \-perl
>    |-smoke
>    |  \-qt
>    |    \-...
>    \-bindings files
>
> Don't you think we can make it work as it is?  If there's a
> Makefile.PL at the top level, and a Makefile.PL in the smoke directory
> that builds smoke for us, and a Makefile.PL in the perl dir that
> builds the bindings, wouldn't that work?  Then we could keep our
> structure similar to that of kde-bindings, so it's easy for us to
> commit there when we're ready, and will integrate nicely with their
> CMake build system.
>
> On Wed, Jun 3, 2009 at 11:29 AM, Jonathan Yu <jonathan.i.yu at gmail.com> wrote:
>> Eric, et al:
>>
>> Sune (pusling) on IRC mentioned this to me.
>>
>> It looks as if it does exactly what we need. I'll work on writing a
>> patch to our Build.PL/etc to get it to configure the flags properly
>> :-)
>>
>> I want also to make sure users can override it, in case pkg-config
>> isn't installed. So perhaps we can offer an environment variable that
>> will determine the paths. I'll need to hack on that; when I have it
>> relatively tested I'll commit something that we can test :-)
>>
>> (Something I also want to work on -- perhaps I can take a branch of
>> the trunk -- is separating the qtsmoke stuff from the actual Perl
>> binding source)
>>
>> Cheers,
>>
>> Jonathan
>>
>> On Wed, Jun 3, 2009 at 2:25 PM, Eric Wilhelm
>> <ewilhelm at scratchcomputing.com> wrote:
>>> # from Jonathan Yu
>>> # on Monday 01 June 2009 15:13:
>>>
>>>>What I'd really like to see is a command like pkg-config for Qt. How
>>>>hasn't this come up before?
>>>
>>> My qt-4.5.1 install has a full complement of .pc files.
>>>
>>> e.g.
>>>  pkg-config --libs QtGui
>>>
>>> Does this not do what we need?
>>>
>>> See also ExtUtils::PkgConfig, though it doesn't seem to be super
>>> rigorous about checking the exit code of backticks, it does at least
>>> provide some level of abstraction.
>>>
>>> --Eric
>>> --
>>> I arise in the morning torn between a desire to improve the world and a
>>> desire to enjoy the world. This makes it hard to plan the day.
>>> --E.B. White
>>> ---------------------------------------------------
>>>    http://scratchcomputing.com
>>> ---------------------------------------------------
>>>
>>
>