[Kde-perl] Alien:: package (was: Qt Compile Flags)

Eric Wilhelm ewilhelm at scratchcomputing.com
Thu Jun 4 01:08:42 CEST 2009


# from Jonathan Yu
# on Wednesday 03 June 2009 13:36:

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

I get what you're saying, but I think it would be simpler to maintain if 
Alien::SmokeQt is a static dependency which itself deals with the 
prodding and poking and prompting.  See Alien::wxWidgets for example:

  1. users says `cpan Wx`
  2. cpan gets Wx-$latest.tar.gz, unpacks it, runs Makefile.PL
  3. Wx requires Alien::wxWidgets > $some_version
  4. cpan gets Alien-wxWidgets-$latest.tar.gz, unpacks it, runs Build.PL
  5. Build.PL pokes around your system looking for a wx
     a. finds one, notes that location
     b. doesn't find one, prompts (defaults to ok)
        * downloads a tarball from sourceforge or whatever
        * unpacks, runs ./configure, make
  6. ./Build install puts @stuff in your @INC

Now, if your situation was case 5a (say, debian unstable), @stuff is 
just an Alien/wxWidgets.pm (and one other .pm).  If 5b, @stuff also 
includes e.g. a gtk_2_8_8_uni/ directory with the lib/libwx_*.so and 
such files in it.

The upshot of all of this is that no matter whether wx and/or 
Alien::wxWidgets was a debian package or installed on-the-fly, 
this "just works"

  perl -MAlien::wxWidgets -E 'say Alien::wxWidgets->version'

And then the installer for the Wx dist just uses methods like 
Alien::wxWidgets->shared_libraries() to build itself.

Of course, now that I look at App::Info, I see that it's basically that 
same kind of thing -- but Alien::wxWidgets predates it.  The main 
difference seems to be that the presence of Alien::wxWidgets asserts 
that wxWidgets is installed (also see Alien::SVN.)

So, how about making Alien::SmokeQt a subclass of App::Info?  (or 
something like that -- bin_dir() and executable() won't really mean 
that much, but App::Info::Lib::Expat seems to be something of a 
precedent.)

--Eric
-- 
"Beware of bugs in the above code; I have only proved it correct, not
tried it."
--Donald Knuth
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------


More information about the Kde-perl mailing list