Note: I'm not advocating this a good solution to your problem. It is simply the only solution that I can think of to your problem as stated.

The idea of using PERL5OPT & -MYour::Filter could (be made to?) work, given a little imagination and a lot of need.Your correct that -M effectively does a use in the main script, but the combination has several things going for it.

• Environment vars a a convenient way of enabling/and disabling thing globally.
• Modules loaded this way are loaded beforethe modules used within the script.
• The module you are loading is a source filter.

The combination of factors means that your source filter will have the opportunity to filter all the other use & require statements in the main module.

You could therefore, intervene in those statements and apply your own logic to them. You might for example, create a temporary additional libpath to @INC and whenever you see a use or require statement, copy the referenced module from it's standard location to the appropriate place in your extra libtree, adding a use Your::Filter into the source of the module just after the package statement as you copied it. You then pass the use or require statement back to the compiler unchanged. It does it's usual thing of looking in @inc to locate and read the module, except it reads your modified copy from the temporary libtree you added to the front of @INC instead, and whizzo:). You now get to filter the module. Your filter then gets called recursively to filter any modules imported by that module ...

Were I going to do this, I would code my asserts and debug code in the modules as comments rather than code using some notation on the front of the comment to indicate that this is a debug/test line. Eg.

##debug## assert( $thing_to_check );
##debug## warn 'doobree=', $whatsit;
[download]

and the filter, when enabled would look for these special comments and remove the comment card. This simplifies the filter in that you a) only need inspect comments and b) have a very definitive and easy edit to make. It also means that you only need the filter for testing and debugging, and you disable it in production which reduces the overhead for the production code not only by removing the debug and trace code, by also the filtering itself.

That said, unless your test and debug code was already coded this way to start, you would need to edit the 100's of modules to add the comment cards, in which case you may consider it much simpler to write a script to iterate through your 100's of modules and insert the appropriate use Your::Filter after the package statement.

In truth, I probably wouldn't consider doing any of this on my codebase, but then I can't see your codebase, and I don't see the true nature of the problem that you are trying to address. Suffice it to say. If you really need to do this, perl does provide all the tools you need to do it. They may not be as simply to apply as you would like, but there is rarely a time when you could say "It can't be done.".

I thoroughly enjoyed thinking about how I might tackle the problem you posed.

Should you choose to take the mission, I wish you the best of luck, but will deny any and all involvement should you get caught.

This post will self-destruct 15 seconds after you take the idea seriously:)