# from Johan Vromans
# on Monday 12 November 2007 00:20:
>> If you want to use App::, I think you'll have to build heavier
>> distros which have lib/App/Foo.pm. But, maybe program_name implies
>> script_files or something.
>
>I don't see a fundamental different between a small, single-file user
>program and a user program with its own library of application
>specific modules. To the end user, its a user program.
That doesn't even relate to this.
>Besides, I hate 'bin' since its a misnomer anyway. 'app' (note:
>lowcase letter a) would already be better.
>
>But I rather not start the discussion again.
Then bin:: it is. You may also use script:: (or app:: if you want to
mess with the script_files parameter.)
The only actual requirement is that the version number be set in some
package name which matches the filepath relative to Build.PL
Thus, "program_name => 'bin/foo'" will require $bin::foo::VERSION to be
set and create a distro called "bin-foo". While setting "program_name
=> 'script/foo'" will require $script::foo::VERSION and yield a distro
name of "script-foo".
program_name => 'bin/foo';
Would expect $bin::foo::VERSION and give you a 'bin-foo-v0.0.1.tar.gz'
tarball.
I thought about allowing the '/' to be '::' or '-', but I think we
should just stick strictly to the '/'.
I'm thinking it would be convenient to also make cgi-bin and sbin work
along these same lines. App::Build seems to have addressed some of
that, but the tricky bit appears to be the "standard install
locations."
But, for this discussion, does setting program_name => 'cgi-bin/foo'
translate into searching for $cgi::bin::foo::VERSION, or
$cgi_bin::foo::VERSION, or something else? (i.e. in-general, the '-'
is allowed and translated as an '_', but otherwise any randomly invalid
module name probably just throws an error.
And anyway, set dist_name and dist_version the hard way if you don't
like it, right?
--Eric
--
But you can never get 3n from n, ever, and if you think you can, please
email me the stock ticker of your company so I can short it.
--Joel Spolsky
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
