Re: [DTrace-devel] [PATCH] configure: accept standard installation directory options

[Nick Alcock <nick.alcock@oracle.com>]

On 4 Mar 2026, Kris Van Hees verbalised:
> On Wed, Mar 04, 2026 at 08:19:42PM +0000, Nick Alcock wrote:
>> On 4 Mar 2026, Kris Van Hees via DTrace-devel verbalised:
>> > diff --git a/configure b/configure
>> > index cb2f585a..96a13137 100755
>> > --- a/configure
>> > +++ b/configure
>> > @@ -53,16 +53,30 @@ help()
>> >  Installation paths:
>> >  
>> >  --prefix=/usr					Prefix of all installed paths
>> > +--exec-prefix=PREFIX				Prefix of arch-dependent paths
>> >  --objdir=build					Build directory
>> >  --libdir=PREFIX/lib64				Library directory
>> >  --bindir=PREFIX/sbin				Binary directory
>> >  --sbindir=PREFIX/sbin				Alias for --bindir
>> > +--libexecdir=PREFIX/libexec			Program executables directory
>> > +--sysconfdir=PREFIX/etc				System configuration directory
>> > +--sharedstatedir=PREFIX/com			Arch-independent data directory
>> > +--localstatedir=PREFIX/var			Runtime system data directory
>> > +--runstatedir=PREFIX/var/run			Per-process data directory
>> >  --includedir=PREFIX/include			#include directory
>> > ---mandir=PREFIX/share/man			Manpage directory
>> > ---pkg-config-dir=PREFIX/share/pkgconfig		Pkg-config directory
>> > ---udevdir=PREFIX/lib/udev/rules.d		udev rules directory
>> > ---systemd-unit-dir=PREFIX/lib/systemd/system	systemd unit directory
>> 
>> Did you mean to entirely disappear this option? It would still have an
>> effect if it was kept.
>
> Is it actually used in any way?  From what I have been able to see, the unit
> directory is always SYSTEMDDIR/system, just like the presets always seem to
> go in SYMTEMDDIR/system-preset (for which we never had a specific option
> anyway), so it would seem that --systemd-dir is sufficient.

Well, you can set it, and it affects where the unit files are installed.
Whether this is an option worth providing is another matter -- I was
trying to ensure that every path we installed things in could be
customized, whether or not you could coerce (e.g.) systemd into actually
looking for things in those other places. (From a quick check, it looks
like systemd does not allow customization of these paths, so probably
prefix and DESTDIR support is sufficient and nobody would ever customize
--systemd-unit-dir directly except for per-user installation under $HOME
-- which nobody would ever do with DTrace because it has to run as
root.)

So, yeah, drop it :)

>> > ---docdir=PREFIX/share/doc/dtrace		Documentation directory
>> > +--oldincludedir=PREFIX/include			#include directory (non-gcc)
>> > +--udevdir=PREFIX/lib/udev/rules.d		Udev rules directory
>> > +--systemd-dir=PREFIX/lib/systemd		Systemd config directory
>> > +--datarootdir=PREFIX/share			Arch-independent data root
>> > +--datadir=DATAROOTDIR				Arch-independent data directory
>> > +--pkg-config-dir=DATADIR/pkgconfig		Pkg-config directory
>> > +--infodir=DATARIR/info				Info documentation directory
>> > +--localedir=DATADIR/locale			locale specific data directory
>> > +--mandir=DATADIR/man				Manpage documentation directory
>> > +--docdir=DATADIR/doc/dtrace			Documentation root directory
>> > +--htmldir=DOCDIR				Html documentation directory
>> > +--pdfdir=DOCDIR					PDF documentation directory
>> > +--psdir=DOCDIR					PS documentation directory
>> >  --testdir=LIBDIR/dtrace/testsuite		Testsuite install directory
>> 
>> Nice!
>> 
>> ... really the number of these is quite overwhelming now. I think we
>> need a little more structure. It might be worth indicating in the help
>> output which options have no effect, though, since some of them do have
>> an effect indirectly, like --datarootdir, but some have no effect at
>> all, like --oldincludedir. I'm honestly shocked --oldincludedir still
>> exists -- I've never seen anything at all that uses it. Maybe GCC
>> pre-2.7.x?
>> 
>> Maybe these should be moved to separate --help sections, maybe titled
>> 'Installation paths affecting other paths' and 'Unused paths accepted
>> for compatibility only'?
>
> The help already shows the way the different settings affect one another, so I
> don't see what extra thing we can do here.  Moving them to a separete section
> seems odd because that means they get separated from one another.

True.

> Also, while we could spell out unused paths that are accepted for
> compatibility, none of the packages I looked at for reference seem to do that.
> According to the coding standard it is also perfectly fine to ignore them
> (i.e. silently accept them).
>
> But if you feel strongly about this, we can definitely move them to their own
> section.

I just think the sheer number of them is getting a bit much. Moving the
compat ones out of the way at least means that it's easier to grasp the
ones that have an effect.

> In summary:
>
>  - I think that using --systemd-dir and deprecating --systemd-unit-dir is a
>    valid change, especially since we hve the inconsistency of having had that
>    specific option for the unit file directory but not for the presets.

Agreed. (Mea culpa.)

>  - I don't think it makes sense to separate out the options for paths that have
>    effects on other paths, since grouping them all together as they are in this
>    patch actually documents how they relate to one another.

Agreed.

>  - I will move the unsused options to their own sub-section in the help to show
>    they exist for compatibility only.  If we ever end up using them, we can
>    move them.

Agreed.

> DOes that sound ok?

Absolutely. We are in violent agreement :)

-- 
NULL && (void)