Please note that the POD renderer here is changing the L links to "the Module::Name manpage" and breaking the links. I have reposted to a GH Gist for those who would prefer: https://gist.github.com/1616923
Hey, how this grant would relate to the other "Easy Installation for non Perl modules" grant that is also waiting approval?
I wasn't going to comment on that, but now that you have asked. Of course this may be biased.
I think that that mechanism has a distinct flaw in that it depends on there being hooks for each package management system. Further this can only be a Linux solution (and as I said, not even fully cross-linux let alone cross platform). I can't imagine a module author who would add such a system as a dependency which cannot be satisfied on a restrict set of platforms.
I think that if such a mechanism were employed it should be a single use-case inside Alien::Base. That said, when I started the Alien::Base project, I considered all kinds of mechanisms, and I decided that for simplicity and broadest application, I should pick one installation process, namely building from source.
Alien::Base short-circuits if it finds a system installed library, otherwise it builds the library in a File::ShareDir location. It will have hooks to allow downloading pre-compiled packages, in principle it would not be hard to add linux-based package management hooks too. With this system in place module authors can be more confident that the library in question can be installed everywhere.
I want to clarify one thing from my previous comment:
Alien::Base will short-circuit if it finds a system-wide installation of a library. If that is not found then no change is made to the system outside of the File::ShareDir location. This was a design choice I made to because:
1) it is a path of least surprise when installing a Perl module (doesn't affect the system)
2) it is safest
3) doesn't require root privileges (leads to:)
4) works with local::lib/perlbrew
A build from source would be preferred, but of course some Perl (especially Windows) cannot build modules. For this purpose, pre-compiled downloads are possible, though they will still install inside a File::ShareDir location. If I understand PPM, this should be easy to package for AS-Perl.
All that said, hooking in to the platform's package manager to install dependencies must be root and cannot be scoped using File::ShareDir nor be localized with local::lib/perlbrew. If the community really wants this facility it could be added, but I don't have it on my todo list. And again, since there is no standard package manager, this mechanism is neither cross-platform nor even cross-linux.
I sketched out some rough ideas for this sort of thing years ago, but it never got traction. It might be useful to you now as you consider your work: Portable Alien Library System
I'm going to say the same thing for all the grant requests this round ...
As a general rule, I think grants should be used to fund development on projects that are already established.
Speculative projects are just that, speculative. Even if the grant is completed, it's really hard to know whether the resulting work will be useful to anyone.
When funding work on an existing project, we already have some idea of whether or not that project has traction in the wider Perl community.
Perhaps I shouldn't say this, I tend to agree with you actually. Given last quarter's submissions however, I thought that this work was at least worth submitting.
I do know that the PDL Porters are anxiously awaiting some breakthrough in the Alien:: world since the major hinderance to PDL adoption seems to be external dependencies.
(Previous comment (PDL Alien::) was me)
I see this project a little differently, because there are already many Alien modules, many of which are reinventing the wheel. Joel is proposing to extract the reusable bits from what he is already working on, which makes it not really greenfield ("speculative") work.
As I pondered this same topic years ago and never had the tuits, I'm supportive of someone taking the initiative now to define some standard tools for Alien::* packages.
I have, at various times in the past, worked on other people's Alien::-style distributions, written my own (Alien::ROOT must clock in as the single largest install footprint of any Perl module), and written other XS modules that inline some of the typical Alien:: functionality of auto-fetching or building external libraries.
Like David Golden, I've thought many times about abstracting some of the tools into a reusable library. My excuse is that I always found an itchier itch to scratch.
At the proposed expense for the grant, I believe such a library would provide tangible benefit to module authors and it would be a steal.
My only concern is that the proposed library sounds like it may make too many assumptions about the library being built. For that reason, I very much hope that each of the build steps will be overridable/hookable (obtain, extract, configure, build, test, install, package from the top of my head).
+1
My only concern is that the proposed library sounds like it may make too many assumptions about the library being built. For that reason, I very much hope that each of the build steps will be overridable/hookable (obtain, extract, configure, build, test, install, package from the top of my head).
[ '%pconfigure --prefix=%s', 'make', 'make install' ]where %p is './' on linux and %s is the File::ShareDir source.
Of course that is the build process. For the obtain extract etc, I am trying to be extensible and provide a sub-classable api. Remember that the whole system is a subclass of Module::Build and I hope to present it that way. Its not ready yet, but its the goal.
Speaking as a PDL porter, I can say that having a useful starting base for Alien modules would be a huge help. We have a number of libraries that appear to have interest primarily among PDL users and developers, PLplot and Slatec being big ones, and GSL being another. Joel has produced Alien::GSL, but the other two remain open problems and will likely require multiple Alien modules to fix (PLplot requires CMake; Slatec requires a Fortran compiler). Having a base module and a cookbook with ways of wrapping up libraries or compilable binaries would be an enormous help here, and this is the hole that I imagine Alien::Base would fill.
There is, of course, the related proposal about creating a library that knows how to talk with the different Linux packagers. I think that is also a wonderful idea, but should ultimately be folded into the Alien concept. It also does not provide any help to Windows or Mac users, which are two large target audiences of PDL. The PDL Pumpking, Chris Marshall, has worked very hard to make PDL more and more cross-platform with each new release, and I think that we would prefer to see a solution that we can target for all major platforms rather than just Linux.
So, I would endorse this project, contingent upon it having lots of documentation that illustrates how to customize the system and install both executables and libraries.
(Full disclosure: I know Joel from the PDL mailing list, more recently from meeting in person at Chicago.pm, and also from many discussions on #pdl at irc.perl.org.)
PE File is the executable file type in the windows OS, we also know it as the exe, dll and sys file extension. The PEFile tool can be use to get information from the files like pe header structure and Stream (ADS) Information, but not only that, this application can give you a lot more information on a EXE file and it can output the information to HTML file