in reply to RFC: Portable Alien Library System

I'm not sure if I have understood your very technical and verbose specification of things, so please bear with me while I rephrase it in my words it as I understand it:

The "PAL" files are to me just a special case of make dist, which I tentatively call make sneakernet, bundling together the external library sources and Perl glue code into a bloated Alien:: module, thus skipping the download, untar and patch steps. Many external libraries are infected with the GPL or other licenses which prohibit bundling with my Alien:: modules, hence this step will have to be performed by the user needing a sneakernet and no aggregate distribution will be provided by me.

What you call Alien::Base is conceptually what my distributions have as inc::Alien::Util, an evolving set of tools that have proven themselves convenient, like code to fetch an URL, code to gunzip/untar a file, code to find the latest version of something on sourceforge.net or elsewhere.

I'm not sure about site/auto - I use $INC{__PACKAGE__} as the base directory below which the C header files and library object files will be stored. In the end, it won't matter as long as it's consistent, of course. Under Win32, additional external DLLs need to go into the same directory as perl.exe, so they can be loaded by Windows without fiddling with $ENV{PATH} and so they don't pollute the "namespace" under C:\WINNT. I prefer the exact layout of include/ and lib/ below the Alien root directory, because that allows most ./configure or other install scripts to remain unchanged and unpatched.

The generation of binary packages to me is completely beyond the scope of the Alien:: namespace - PPMs are the established way of providing binary packages, and in theory, creation of a PPM for package Foo (relying on libfoo via Alien::LibFoo) should automatically pull in the Alien::LibFoo package via nmake ppm and hence produce a fully working Foo PPM, which can then be distributed and downloaded. To me, Alien:: is about automating the process of compiling from source, not about redistributing binaries.

The searching of already installed external libraries through other ways is secondary to me - on Win32, it is almost certain that external libraries are not installed and hence won't be found unless the Alien:: package knows where to download and how to install the prepackaged binary. Even on unixish systems I prefer libraries that have no external life outside of the Perl directory tree so that a system-wide upgrade of a library doesn't affect any Perl program because the Perl programs link to Alien::SomeLib instead of the system-wide library installation, and thus all Perl programs continue to work as before. Of course, an optional switch to make Alien:: scan for pre-existing installations would be nice to have.

The focus in compiling is to me always static linking of the library into the XS file, to remove one level of dynamism from the Jenga tower of shared libraries. This has the added benefit that a manual transplantation of Foo consists of copying all directories below site/Foo and site/auto/Foo, as Foo.xs gets converted into Foo.dll with libfoo linked into Foo.dll statically.

Replies are listed 'Best First'.
Re^2: RFC: Portable Alien Library System
by xdg (Monsignor) on Sep 24, 2006 at 22:16 UTC
    very technical and verbose specification of things

    Several of us on #win32 had been speaking very vaguely, so I was trying to break the problem down so individual parts could be addressed discretely. Mea culpa.

    I'll add just a few notes in response. I appreciate the thought you've put into it. I definitely need someone with your kind of compiler-fu. As I start taking this towards a proof-of-concept, I'll certainly want to get more of your input.

    What you call Alien::Base is conceptually what my distributions have as inc::Alien::Util

    Yes, though it would also include tools for interrogating a system to determine if external dependencies were already satisfied or for getting metadata about installed external dependencies.

    The "PAL" files are to me just a special case of make dist

    It was intended generically. It could be PPM's in the end, or it could be zip/tgz files. I didn't want presuppose a particular solution.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]
Re^2: RFC: Portable Alien Library System
by tsee (Curate) on Sep 25, 2006 at 07:46 UTC

    Hi Corion,

    thanks for your long comment. As xdg pointed out, we really appreciate your input.

    I'd like to address one point: You say that PPMs are the established way of providing binary packages. I think that's true in a way and false in another. It's the binary package format that is established with ActiveState Perl.
    I know they just rewrote all of the PPM code and supposedly created a really shiny GUI. (I have only seen a couple of screenshots so far.) That's great, but if I am not mistaken, we are not free to use their PPM code with non AS Perl distributions. At least I could not find it on CPAN. This means that if we're building something for any Perl distribution to use, we shouldn't lock ourselves into the PPM cabinet. Do you agree?

    Steffen

[reply]

      I don't agree in the sense that PPM is an established, working system, and producing PPM files needs no PPM code that isn't available already in Module::Build and I guess ExtUtils::MakeMaker. I'm not interested in creating yet another fancy incompatible format and pushing it down users throats, or rather, I'm more under the impression that there won't be users with throats open for this product. I'm not interested in creating a shiny new world order external library packaging factory but more interested in producing working modules that install external libraries via CPAN below Perl, provided that $Config{make} and a working $Config{cc} are available.

[reply]
[d/l]
[select]
        I'm not interested in creating yet another fancy incompatible format and pushing it down users throats, or rather, I'm more under the impression that there won't be users with throats open for this product. I'm not interested in creating a shiny new world order

        I guess this is what it really comes down to. Hey, that's cool. No one is trying to force you to help. We couldn't even if we tried.

        As tsee echoed, your feedback is appreciated. In time, I hope we can win your support through our code, if not our words.

        -xdg

        Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

[reply]

        xdg's design really doesn't care whether it's a .ppm+.ppd file or a .par file (for which there is quite a bit of infrastructure, too, by the way) or something entirely different.

        I mean, let's forget the details of the file format for a bit. It's the easiest problem to solve when it comes to that.

        Steffen

[reply]

In Section Meditations