On Oct 24, 2011, at 4:35 PM, ext Jeremiah Foster wrote:
> On Mon, Oct 24, 2011 at 2:02 PM, Lauri T. Aarnio
> <[email protected]> wrote:
>> On Oct 21, 2011, at 9:33 PM, ext Carsten Munk wrote:
>>> 2011/10/21 Lauri T. Aarnio <[email protected]>:
>>>> On Oct 21, 2011, at 4:05 PM, ext Carsten Munk wrote:
>
>>
>>> OK, that is a fairly clever approach. I wonder if
>>> we could do something similar with the approach we currently use for
>>> cross compilation.
>>
>> Probably not, without risking something else.
>>
>> Perl is an extremely tricky tool, which makes already itself use of far too
>> many "clever" features that are available.
>>
>> One example is that built-in variable $^X is implemented by reading where
>> /proc/self/exe symlink points to.
>> And many scripts actually record that to something what they produce [this
>> was the original reason why SB2 got a special handler for the /proc FS!]
>>
>> This means that you should not install perl anywhere else than to
>> /usr/bin/perl. So something like a simple redirector at /usr/bin, which
>> would determine what version to use and then exec a perl from somewhere
>> else, would just create more problems that what it would solve.
>>
>> The same applies to the locations of the libraries, etc. => In theory it is
>> possible to change the default locations, but in practice it it just a
>> stupid thing to try.
>
> You're spreading FUD. Perl runs a lot of architectures and platforms
> because it is flexible. Because you can't configure it for your
> cross-compilation environment is not the fault of how the language
> gets built. If you have problems, look at tools like perlbrew for
> pointers on how to install many perls, or ask questions on
> perl-5-porters.
No, no. You missed the point completely.
First, I know pretty well what perl is. I'm actually old enough to remember
those times when the first version of perl was posted to the net... and I also
think I know something about how it is used in the real world. You don't have
to try to teach me the basics.
But the question is not at all how *I* would configure something for our
environment, or how *I* would use it in my packages. And it is not only related
to how a language gets built, it is even more related to how it is used. By
someone else than me or you.
Instead, this discussion is about setting up a cross-building environment where
also somebody else's tools and scripts could be safely and efficiently
executed. Without modifications to the perl configuration, and more importantly
without modifications to the tools implemented in perl. Something like perlbrew
is totally unsuitable for such environments.
And my previous post was not about difficulties in installing many perls in
parallel. It is of course possible, but I'm saying that it should not be done
at all that way; if a perl program was written to be executed with
/usr/bin/perl in the build environment, then it must do so. It must not revert
to something like /scratchbox/tools/bin/perl (a practice is SB1, not used in
SB2).
I have spent a lot of time analyzing problems related to these things, and
implemented some environment-level solutions, too. Unfortunately perl (and how
it is used) presents one of the most tricky problem domains in this sense. The
main reason is simple:
Perl and perl programs make up probably the easiest way to leak information
about the build environment to the compiled packages. For example, we have seen
packages that "got infected by SB1" and afterwards work fine in SB1, but don't
work in the real target environment.
Claiming that all this would be "spreading FUD" is just bullsh*t. Uncertainty
isn't involved - this is a been-there-done-that thing.
BR,
Lauri
PS. Note that I'm not claiming that SB2's strategy of overloading /usr/bin/perl
would solve everything. But it is a nice start, fixes many but not all
perl-related oddities.
_______________________________________________
MeeGo-dev mailing list
[email protected]
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
