| 1 |
On 13 December 2015 at 09:41, Andreas K. Huettel <dilfridge@g.o> wrote: |
| 2 |
> Well. We had that idea already, and at some point something barfed, I dont |
| 3 |
> remember the details anymore. Maybe someone else from the team knows. |
| 4 |
> |
| 5 |
> The problem is introducing too many variables that look like something |
| 6 |
> *upstream* might use... |
| 7 |
> |
| 8 |
> (We in addition already had creative variable clashes with the kernel module |
| 9 |
> build system in the past.) |
| 10 |
> |
| 11 |
> "Gentoo Perl" would lead to GPL_... as variable prefix, not really suitable. |
| 12 |
> Kent suggested GPLX_... which I find horrible. GPERL_? GP_? ... |
| 13 |
|
| 14 |
|
| 15 |
Yeah. There's a bit of a potential issue with using the PERL_ prefix |
| 16 |
in that that prefix is heavily overloaded /in perl/ things, and `perl |
| 17 |
-V` subsequently reports all ENV vars with a PERL prefix ( underscore |
| 18 |
or not ) |
| 19 |
|
| 20 |
PERL_MOM=Yours perl -V | grep MOM |
| 21 |
PERL_MOM="Yours" |
| 22 |
|
| 23 |
So using the PERL_ prefix increases our chances we'll pick something |
| 24 |
that will collide, or will mislead somebody into thinking that we're |
| 25 |
using an ENV var that Perl reacts magically to, where the ENV var is |
| 26 |
purely Gentoo and Purely part of our private API ( At least, its |
| 27 |
supposed to be private from the context of a perl interpreter ) |
| 28 |
|
| 29 |
If there was a way to mark those vars so they didn't get exported to |
| 30 |
perl that would help, but it wouldn't reduce the "What does this do" |
| 31 |
impression-confusion. |
| 32 |
|
| 33 |
-- |
| 34 |
Kent |
| 35 |
|
| 36 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives