[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