in reply to Re^4: ifdef in modules
in thread ifdef in modules

Ignorance? I'm just figuring this stuff out now, too :-)

1 - correct. Specifically, at the front of @INC.

2 - correct. Specifically, at the front of @INC (in front of the handler that ifdef put in)

2.1 - when the module is loaded, perl looks at @INC, finds perl5lib, finds the file there, loads it, and compiles it. During that compilation, it sees...

3 - incorrect. It sees the use ifdef, but doesn't reload ifdef (it's already loaded). It does, however, call ifdef->import(). This action turns around, figures out what ifdef parameter was passed on the original commandline (it's stored in an environment variable), and then calls the source filter on your code immediately. Once the source filter is done, perl continues parsing and compiling the rest of your module.

So, actually, it's not as convoluted as you may have thought. ;-) It does seem very convoluted, though.

Replies are listed 'Best First'.
Re^6: ifdef in modules
by clee (Novice) on Jun 15, 2005 at 00:27 UTC

    Ah...so I wasn't close at all :)

    Well, your explanation makes sense, thanks. Unfortunately, that still leaves me at an impasse. There's little value in adding 'use ifdef;' to all my modules, since the whole point of my using it is so that sections tagged with DEBUGGING will only activate during development, but be ignored in production, without any changes to the code. With 'use ifdef;' at the top of every module, I'd have to take it out when promoting to production (since production will not have ifdef). I could just as easily take out the debug code itself instead.

    I suppose I could try 'use if $ENV{DEBUGGING}, ifdef;', but it just feels like what seemed like an elegant debugging solution in ifdef now requires too many workarounds.

[reply]

      Really? If you leave the 'use ifdef' in your code, it will only marginally affect your load time, won't really affect your compile time (just the part of ignoring POD), and won't affect runtime at all.

      Or, another way to look at it is that commenting out the "use ifdef" line is way easier than commenting out all the DEBUGGING lines. :-)

      One minor advantage here is that you can control which files have ifdef in them - by only putting them in the files you actually want to debug at a given time, you can just get your debugging info from those modules - a significantly reduced set of messages which may make it easier to debug. Minor, but still an advantage.

      What's really unfortunate is that the lib module doesn't play too nice here. We could, however, write a new module, say lib::clean, which would go and reorder the @INC such that all CODE refs are pushed to the front. Then you just need to use it:

      package lib::clean;

sub import
{
    my (@coderefs, @rest);

    foreach (@INC)
    {
        if (ref $_ && ref $_ eq 'CODE')
        {
            push @coderefs, $_;
        }
        else
        {
            push @rest, $_;
        }
    }
    @INC = (@coderefs, @rest);
}

1;

      [download]

      And just 'use lib::clean;' after the 'use lib' line. Just testing that, and it seems to work, too.

[reply]
[d/l]

        I'm not really concerned about the negligible load time. The problem is that production servers won't have the 'ifdef' pragma.

        You're right about commenting out 'use ifdef' being easier than commenting out all DEBUGGING lines.

        Anyways, none of that matters now since you've provided me with a workable solution in lib::clean ;). Hmmm...maybe I could override my dev version of 'lib' instead of putting 'use lib::clean' in the code...

        Thanks again!

[reply]

In Section Seekers of Perl Wisdom