It should do exactly what you want, take a look at some other CPAN modules that use it in their Makefile.PL for examples.

Thanks for the hint. What I find not obvious is how most people handle parts of a module that change during install time. I ended up just reading the source from the Makefile.PL and changing the value of $SYSTEMID to the prompted value with a s///. I didn't want a seperate cfg file as this module is loaded a lot. Basically a bunch of vars that define system defineds. (SMTP server, features enabled, log locations, etc.)

-Lee

"To be civilized is to deny one's nature."

The way we do it at my office is via a config file in a specified location relative to our application directories.

All of my modules use either the current working directory as a "root" or pick the file from /etc/whatever.config, depending upon how it's running. This allows for testing with multiple software revisions; we have several software branches.

# Somewhere in your Makefile.PL...
use ExtUtils::MakeMaker qw(prompt);

# Prompt the user for the system ID, offering "Default_id"
# as the default (ie, if they just hit enter without 
# entering any new text)
my $system_id = prompt("What is the system ID", "Default_id");

run_code_to_update_system_id_in_all_files( $system_id );
[download]

/usr/bin/update_system_id.pl new_system_id
[download]

Thanks for the suggestion. The former is basically what I ended up doing. I didn't know if there was a better idiom. The id shouldn't change later so I'm not worried about the update possibility, and in the rare case it does, I can vi it.

Thanks,
-Lee

"To be civilized is to deny one's nature."