'etc' and 'var' equivalents?

[David Lee]

I get the feeling I'm overlooking something obvious, but I don't know
what it is.

A typical UNIX application will be installed something like:
binaries: /usr/bin
man pages: /usr/man
config files: /etc
data;state: /var

MakeMaker supports various "INSTALL...BIN..." and "INSTALL...MAN..."
options to adjust the locations of the "binaries" and "man pages"
aspects of the application. That's fine; I'm happily using those.

But I can't see how to specify the "config files" and "data;state" aspects.

Any thoughts on what I have missed? Or hints or good-practice-tips on
how to specify to MM the application's config and state directories?

[David Golden]

I get the feeling I'm overlooking something obvious, but I don't know what
it is.
  binaries:      /usr/bin
  man pages:     /usr/man
  config files:  /etc
  data;state:    /var
MakeMaker supports various "INSTALL...BIN..." and "INSTALL...MAN..." options
to adjust the locations of the "binaries" and "man pages" aspects of the
application.  That's fine; I'm happily using those.
But I can't see how to specify the "config files" and "data;state" aspects.
Any thoughts on what I have missed?  Or hints or good-practice-tips on how
to specify to MM the application's config and state directories?

Two separate issues: (1) telling your application where to put things
and (2) telling MakeMaker where to put things.

Many people seem to be finding that it's easier to use File::ShareDir
to access non-code config or data files in a known location within the
perl installation hierarchy. This frees you from having to worry
about whether there is an 'etc' or 'var' directory on a user's system.
E.g. on Windows or for a non-root user on a shared hosting
environment.

Module::Install or Dist::Zilla make it very easy to configure a
Makefile.PL to install files from a 'share' directory in your
distribution directory to the place where File::ShareDir expects to
find them.

--- David

[David Golden]

So in this context, putting config files (read-only), and especially putting
data/state files (read/write), into the perl installation hierarchy seems
inappropriate; the natural mindset for the application would be the
traditional UNIX "/etc" and "/var" locations, plus or minus considerations
such as "Linux Standard Base" (LSB) conventions.
Hence my wondering whether, just as "INSTALLBIN" (and similar) default to
LSB-like conventions and perspective (rather than within the perl
installation hierarchy), there might be analogous "INSTALL*" variables for
LSB-like config ("/etc"-ish) and data/state ("/var"-ish) locations.

These do not exist by default. (The INSTALLBIN targets come from the
Config module and are set during perl compilation and only
perl-relevant directories are there.)

There are two (maybe three) steps to what you want to do:

(1) customize the "make" action to put files into blib/etc and blib/whatever

(2*) (*optional) customize your tests to look in blib/etc and so on
for things needed during testing

(3) customize the "make install" action to copy from blib/etc to /etc

I'm more familiar with how to do that using Module::Build -- see the
Module::Build::Cookbook on search.cpan.org in these sections:
# Adding new file types to the build process
# Adding new elements to the install process

Hopefully, someone familiar with how to do this with MakeMaker will be
able to give you more advice. There may also be plugins for
Module::Install to do this, but I don't know of any, myself.

Another good place to ask questions like the ones you have is
#toolchain on IRC at irc.perl.org -- you'll get a cross section of
EU::MM, M::B, and M::I experts there.

-- David

[David Lee]

Post by David Golden

Post by David Lee
[...]
But I can't see how to specify the "config files" and "data;state" aspects.
Any thoughts on what I have missed? Or hints or good-practice-tips on how
to specify to MM the application's config and state directories?

Two separate issues: (1) telling your application where to put things
and (2) telling MakeMaker where to put things.
Many people seem to be finding that it's easier to use File::ShareDir
to access non-code config or data files in a known location within the
perl installation hierarchy. This frees you from having to worry
about whether there is an 'etc' or 'var' directory on a user's system.
E.g. on Windows or for a non-root user on a shared hosting
environment.
[...]

Thanks for the reply, and my apologies for delaying in acknowledging it.

This is an application which just so happens to be in Perl at the
moment. It could have been in other languages. As far as the users are
concerned their access points will be thin binary wrappers in their
$PATH ("/bin" or similar), not anything perl-ish (the fact it is in perl
is merely an internal implementation detail for me as its coder, and for
the app. administrator who installs it as "just another CPAN module").

Likewise, from the perspective of the app. admin. (and his/her
end-users) the config and data/state files for this application have
nothing perl-specific about them. (OK, they'll be read/written by the
heart of the application which just so happens to be in perl.)

So in this context, putting config files (read-only), and especially
putting data/state files (read/write), into the perl installation
hierarchy seems inappropriate; the natural mindset for the application
would be the traditional UNIX "/etc" and "/var" locations, plus or minus
considerations such as "Linux Standard Base" (LSB) conventions.

Hence my wondering whether, just as "INSTALLBIN" (and similar) default
to LSB-like conventions and perspective (rather than within the perl
installation hierarchy), there might be analogous "INSTALL*" variables
for LSB-like config ("/etc"-ish) and data/state ("/var"-ish) locations.

If there aren't such variables, then I'm happy to hack it. (But I'd
rather use established routes where possible.)

If I'm heading in the wrong direction, do let me know!