in reply to Re^4: perl interpreter must be named my_perl?
in thread perl interpreter must be named my_perl?

In a non-MULTIPLICITY build, those macros are all undefined. They don't mention my_perl

But MULTIPLICITY is the de facto default build option, Am I right?
  • Comment on Re^5: perl interpreter must be named my_perl?

Replies are listed 'Best First'.
Re^6: perl interpreter must be named my_perl?
by ikegami (Patriarch) on Dec 01, 2023 at 19:22 UTC

    Just to be clear, I said the global my_perl isn't used by the THX macros with or without MUTLIPLICITY.

    As for MULTIPLICITY being the default? No. It's is off by default.

    MULTIPLICITY is what allows a process to have multiple interpreters. A build with thread support requires MULTIPLICITY since each thread has its own interpreter. So MULTIPLICITY is automatically defined when a building Perl with thread support.

    A build without thread support usually won't use MULTIPLICITY. If the OP's program only needs one interpreter, they should use a build of Perl that was built without MULTIPLICITY (for a performance boost).

[reply]
[d/l]
[select]
Re^6: perl interpreter must be named my_perl?
by bliako (Abbot) on Dec 01, 2023 at 08:05 UTC

    I would avoid words like "de facto, default" and just do my own checks:

    linux perlbrew:

    perl -V | grep -i multi
      usemultiplicity=undef

    [download]

    linux system perl:

        usemultiplicity=define
Compile-time options:
    ...
    MULTIPLICITY

    [download]

    I liked Multiplicity - what the heck is it?

    bw, bliako

[reply]
[d/l]
[select]
[reply]
[d/l]

In Section Seekers of Perl Wisdom