I maintain PDF::Burst and PDF::OCR2. This concerns PDF::Burst, and setting class variables.

I had some issues using PDF::OCR2 with certain pdf documents. Some I had bad xref tables.. For example. I recently found that some of the documents were failing but it was because PDF::Burst was failing. The simple alternative was to tell PDF::Burst to use another of the three methods (for bursting a pdf into many pages).

My default class variable is set to PDF::Burst::BURST_METHOD = 'CAM_PDF', this can be overriden byt setting it to something else or calling the burst 'methods' directly.

The test suite for PDF::Burst tries out the various 'methods' for bursting a pdf.

I would like to record a default burst method in the class, variably from system to system. That is, for some system (box), the class variable will be x, and for some y. (Keep in mind this can be overriden at any moment by API directly, it just sets a default- instead of a default hard coded, it sets a default varying by system.)

I have these options I can think of;

1. When PDF::Burst compiles, it seeks out a /etc/pdfburst.conf for which default value to set for the class variable.
2. When PDF::Burst compiles, it seeks out a ~/.pdfburstrc for which default value to set for the class variable.
3. When Makefile.PL is run, it changes the hard coded variable in lib/PDF/Burst.pm (this would mean from system to system, the module will have varying md5sums, (is that a potential problem? I can imagine how it would be, out of scope here.))

   This is the tickleiest option for me. How would I even begin to do this? I mean, yeah. I know how.. but.. it seems brute force to simply search and replace code in a .pm

4. Don't do this at all. Leave changing this PDF::Burst class variable for other packages/cli who use the class (such as PDF::OCR2). I'm open to the idea that this is just overkill.