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

Tue Jun 2 13:40:57 UTC 2009

Oh, also, I've been discussing this with Chris Burel directly
off-list. I'm not sure if he's currently subscribed to this mailing
list.

Currently what we are doing is using CMake to build both the Smoke
libs and our bindings.

I want to separate it so that CMake only builds the Smoke libs (which
may or may not be included in our dist) and so Perl builds the Perl
libs, essentially inverting the module hierarchy.

Instead of:

PerlQt/perl/... etc

It would be:
PerlQt/src/smoke/... etc

So the Perl Makefile.PL goes into those dirs, and does cmake et al if
it doesn't exist on the system. The point is that we should check if
there is a system-installed library *first*, before building, and
either warn the user or tell him/her we can build it for them. Chris
sees a use for the latter; however, I don't think it's entirely
necessary. I think users should be reasonably expected to download
those files (given our instructions of course) and told to compile and
install them beforehand.

This is exactly what DBD::Pg (the DBI PostgreSQL driver) does. It
expects users to have installed pgsql's libraries beforehand (libpq et
al) -- and if they are not installed, then the Perl bindings won't
build, and a message will be shown to the user.

Cheers,

Jonathan

On Tue, Jun 2, 2009 at 9:35 AM, Jonathan Yu <frequency at cpan.org> wrote:
> Richard:
>
> Here's the way I see it -
>
> Yes, Perl can be adapted to do the whole cmake build and everything.
>
> However, that's not how most Perl modules are built, which is
> problematic because I want to distribute the package via CPAN. That
> means we have to separate the parts that require cmake and all (which
> the user should do by hand, or through a Perl Alien:: package, or with
> a package manager like APT), from the Perl part (the actual
> bindings/XS files/etc).
>
> I see no reason for the dependencies to always be built, if the user
> has already installed them on his/her machine.
>
> So all the Perl part should be doing is checking "is it installed? no?
> emit an error message and die."
>
> It is up to the user to download and install the CMake/Smoke/etc stuff.
>
> One issue with putting Cmake/Smoke/etc as part of our install is that
> there is a chance that our Qt bindings become out of sync with the
> upstream version of libsmoke etc. However, if we use a
> system-installed smoke, then we can assume that it is fully compatible
> with the current version of Qt installed.
>
> Thoughts?
>
> Cheers,
>
> Jonathan
>
> On Tue, Jun 2, 2009 at 6:51 AM, Richard Dale <rdale at foton.es> wrote:
>> On Monday 01 June 2009 11:13:31 pm Jonathan Yu wrote:
>>> Hm.
>>>
>>> I did manage to track down the issue.
>>>
>>> Your Makefile.PL expects stuff to be in /opt... However on Debian it is
>>> not.
>>>
>>> On GNOME and other packages, it comes with a command (GNOME has
>>> pkg-config) which will return compiler flags, so when you do
>>> Makefile.PL you can do: `pkg-config --cflags` to get compiler flags,
>>> which get passed directly to gcc.
>>>
>>> From Google it seems there is no established way to do this (ie via
>>> pkg-config), which is too bad. So that means for the purpose of
>>> developing bindings, we need to figure out a list of common places Qt4
>>> is going to be installed. The problem is, too, that we want our
>>> bindings to be compatible with the whole of Qt, rather than just Qt
>>> 4.5.2 or whatever. So that's a lot of work to do.
>>>
>>> What I'd really like to see is a command like pkg-config for Qt. How
>>> hasn't this come up before?
>>>
>>> Cheers,
>>>
>>> Jonathan
>>>
>>> On Mon, Jun 1, 2009 at 5:59 PM, Jonathan Yu <jonathan.i.yu at gmail.com> wrote:
>>> > Hi:
>>> >
>>> > I'll get you a build log as soon as I can. I got it to build on my
>>> > system following your instructions in README, but the Perl stuff
>>> > didn't compile, so you can't load Qt.
>>> >
>>> > Based on what I understand of the instructions, cmake seems like a
>>> > precompiler type thing that doesn't actually build anything - that's
>>> > what the 'make' part  after is for. Does that mean we can distribute
>>> > the CMake'd stuff without doing the final compilation?
>>> >
>>> > Cheers,
>>> >
>>> > Jonathan
>>> >
>>> > On Mon, Jun 1, 2009 at 2:58 PM, Chris Burel <chrisburel at gmail.com> wrote:
>>> >> Hey Jonathan,
>>> >> CMake actually builds the bindings.  So if this completes successfully:
>>> >> mkdir PerlQt4/build && cd PerlQt4/build
>>> >> cmake .. <with any additional options>
>>> >> make
>>> >>
>>> >> then there should now be a PerlQt4/build/perl/blib directory that
>>> >> contains the compiled parts of the bindings.  However, it doesn't
>>> >> contain the .pm files, because I couldn't figure out how to get CMake
>>> >> to put them there, because they're not compiled.  All that needs to
>>> >> happen is to do
>>> >> cp -r PerlQt4/perl/lib PerlQt4/build/perl/blib
>>> >>
>>> >> Then, in order to be able to run the examples:
>>> >> ln -s ../build/perl/blib PerlQt4/perl/blib
>>> >>
>>> >> Using CMake, you don't have to run the Makefile.PL at all.
>>> >>
>>> >> The reason I switched to CMake is because that's what the kdebindings
>>> >> package uses, and the Smoke object gets built using CMake.  Since I
>>> >> knew what it took to compile the bindings, but didn't necessarily know
>>> >> what it took to generate and compile smokeqt, I converted the build
>>> >> system over to cmake so that you could build the smokeqt object and
>>> >> the bindings at the same time.  I understand that that presents a
>>> >> problem for uploading it onto CPAN.  If you want to figure out how to
>>> >> build the smokeqt object with the Makefile.PL file, go right ahead.
>>> >> If you don't want to use CMake, you can still build the bindings with
>>> >> the Makefile.PL method, but it requires you to build smokeqt
>>> >> externally.  There's a couple paths in Makefile.PL that are
>>> >> hard-coded; you could easily externalize those paths and have them
>>> >> passed in via flags.  But integrating the smokeqt build is a bit more
>>> >> work.
>>> >>
>>> >> On Mon, Jun 1, 2009 at 11:14 AM, Jonathan Yu <jonathan.i.yu at gmail.com>
>> wrote:
>>> >>> Hi Chris:
>>> >>>
>>> >>> I have been trying to install your bindings.
>>> >>>
>>> >>> I do the cmake and everything completes properly.
>>> >>>
>>> >>> However, once I try to compile the Perl bindings themselves by doing:
>>> >>> cd PerlQt4/perl
>>> >>> perl Makefile.PL
>>> >>> make
>>> >>>
>>> >>> I get a bunch of errors like: Qt.xs:2:24: error: QtCore/QHash: No such
>>> >>> file or directory
>>> >>>
>>> >>> So I'm guessing it's something perhaps missing from the include paths
>>> >>> (in -I)
>>> >>>
>>> >>> As well, the distribution itself doesn't seem very Perl-ish at all. Is
>>> >>> CMake a precompiler-type language, where we will distribute a copy of
>>> >>> the perl directory that has already been cmake'd?
>>> >>>
>>> >>> Lastly, I think 'use blib' can be replaced with 'use
>>> >>> ExtUtils::testlib' which is more appropriate, since it makes it look
>>> >>> in blib as necessary. That module is also a core module which is nice.
>> Although Ruby has a standard build system for extensions, it isn't used in
>> QtRuby because it isn't really powerful enough. So the QtRuby extensions are
>> built with cmake. Isn't it possible to adapt PerlQt and Perl to work with
>> cmake too?
>>
>> -- Richard
>> _______________________________________________
>> Kde-bindings mailing list
>> Kde-bindings at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-bindings
>>
>