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

[Jonathan Yu]

Chris:

I don't think normal installs are a problem, per se, I just have no
experience setting up that sort of thing.

It's easier to find things when they're system-installed -- you can
check in the usual library paths. However, when they're installed in
the user directory, they can really be anywhere. So the App::Info
instance would need to be able to account for that. Just adds a bit of
extra complexity, and I'm not sure how the other modules do that sort
of thing.

Anyway, I think all of this is nice to have discussed up front, but it
should be put on the back burner for now. Right now the big push is
fixing that nasty issue with the segfaults, so I'll fix my module,
finish compiling and hack on that. :-)

Cheers,

Jonathan

On Wed, Jun 3, 2009 at 4:54 PM, Chris Burel <chrisburel at gmail.com> wrote:
> I used the Makefile.PL because that's what
> h2xs -A -n Qt
> gave me.  It compiled what I needed, so all was good.  If you guys
> think we should use Module::Build, and want to convert over, be my
> guest.
> It also sounds like a good idea to package smokeqt as an
> Alien::SmokeQt package.  Remember that there are Smoke objects for
> different parts of Qt, KDE, Phonon, etc, that are all separate.  For
> instance, qtuitools, qt, and qtscript all have separate smoke objects.
>  So we'd want the module called Alien::SmokeQt, so that in the future
> we can have Alien::SmokeQtUiTools, Alien::SmokeQtScript, etc.  I'd
> vote for Alien::SmokeQt over Alien::QtSmoke because the library that
> gets built is called libsmokeqt, not libqtsmoke.
>
> I don't see why you wouldn't be able to tell the Alien::SmokeQt
> package to install to your home directory, and then have PerlQt link
> to it from there.  Why would normal user account installs be a
> problem?
>
> On Wed, Jun 3, 2009 at 1:36 PM, Jonathan Yu <jonathan.i.yu at gmail.com> wrote:
>> Eric:
>>
>> Actually, an Alien:: package (or several) seems like a good idea.
>>
>> One thing I'm not sure about, though, is whether Alien:: packages
>> should be designed to work with normal user accounts (ie non-root CPAN
>> installs). I'm not even sure what package to use as a reference for
>> this -- I did look at Alien::Judy which is a simple enough package
>> that I can sort of grasp what is happening.
>>
>> Moreover, I'd want to reduce the build dependencies if possible,
>> especially in the case where there are modules already installed on
>> the system. I'd like it if users didn't have to download the Alien::
>> stuff if App::Info detects that it's already installed (App::Info
>> would be a build dependency, rather than a full out dependency).
>>
>> This is particularly useful for people that are on systems like, say,
>> Debian.. where the trick is to find out if there is a system-installed
>> version, or ask the user otherwise. Perhaps the Alien package could be
>> used as a convenience, more like:
>>
>> 1. Download App::Info for Smoke
>> 2. Check if libsmokeqt is installed
>> 3. If it is, then use it; otherwise:
>> 4. Prompt the user to install it, ask if it's okay, etc (maybe EUMM's
>> prompt subroutine can be used for this)
>> 5. Install Alien::Smoke etc via CPAN
>>
>> If the lib is already installed, then (as detected by App::Info), then
>> you wouldn't need to install the Alien version via CPAN. Thus
>> Alien::Smoke wouldn't be a direct dependency.
>>
>> Cheers,
>>
>> Jonathan
>>
>> On Wed, Jun 3, 2009 at 4:07 PM, Eric Wilhelm
>> <ewilhelm at scratchcomputing.com> wrote:
>>> # from Jonathan Yu
>>> # on Wednesday 03 June 2009 13:00:
>>>
>>>>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).
>>>
>>> One idea here is to have an Alien::Smoke and/or Alien::Qt packages (ala
>>> Alien::wxWidgets) which allows you to break those dependencies into
>>> separate dists -- so you can automatically install everything with the
>>> cpan client, but you can also quickly upgrade the Qt4 dist for
>>> perl-only changes.
>>>
>>>>do you mind if I upgrade the build over to Build.PL?
>>>>...is much more capable of handling complex tasks than Makefile.PL
>>>
>>> I'll second that.  (Disclaimer:  I'm the Module::Build maintainer.)
>>>
>>> --Eric
>>> --
>>> The opinions expressed in this e-mail were randomly generated by
>>> the computer and do not necessarily reflect the views of its owner.
>>> --Management
>>> ---------------------------------------------------
>>>    http://scratchcomputing.com
>>> ---------------------------------------------------
>>> _______________________________________________
>>> Kde-perl mailing list
>>> Kde-perl at kde.org
>>> https://mail.kde.org/mailman/listinfo/kde-perl
>>>
>> _______________________________________________
>> Kde-perl mailing list
>> Kde-perl at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-perl
>>
> _______________________________________________
> Kde-perl mailing list
> Kde-perl at kde.org
> https://mail.kde.org/mailman/listinfo/kde-perl
>