bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MKDIR_P invocations


From: Bruno Haible
Subject: Re: MKDIR_P invocations
Date: Mon, 20 Dec 2021 10:08:03 +0100

Paul Eggert wrote:
> > It would be possible to replace, in the module descriptions:
> > 
> >     $(MKDIR_P) '%reldir%' && \
> > 
> > with
> > 
> >     { test '%reldir%' = '.' || $(MKDIR_P) '%reldir%'; } && \
> > 
> > It's a micro-optimization. A trade-off between execution speed and
> > readability.
> 
> Emacs is already doing those 
> mkdirs in a different way in configure.ac:
> 
> if $gl_gnulib_enabled_dynarray || $gl_gnulib_enabled_scratch_buffer; then
>    AS_MKDIR_P([lib/malloc])
>    if test $AUTO_DEPEND = yes; then
>      AS_MKDIR_P([lib/deps/malloc])
>    fi
> fi
> 
> None of the Gnulib-generated mkdirs are needed

That's precisely because you have extra code in configure.ac. With the
MKDIR_P calls now in the module descriptions — as needed for VPATH builds
of Automake based packages —, you can remove the
     AS_MKDIR_P([lib/malloc])
line.

> and the Gnulib-generated 
> mkdirs don't generate lib/deps/malloc like they should.

That's because the AUTO_DEPEND mechanism is unique to Emacs and has
no particular support in gnulib-tool.

> From the Emacs 
> point of view it'd be better if the rules didn't do any mkdirs, either 
> of '.' or of 'malloc'.
> 
> How about if we do these mkdirs at configure-time, instead of at 
> build-time, like Emacs is already doing?
> ...
> It's more than just the optimization.

In which respect is it more than the optimization? Redundant $(MKDIR_P)
calls don't hurt. You may feel that perfection is not achieved if
there are redundant $(MKDIR_P) calls.

In my feeling, perfection is not achieved when there are empty directories
after the build. While the GNU standards [1] say that "make clean" and
"make distclean" should only delete files, I consider it proper behaviour
to also delete the respective created directories. Gnulib achieves this
through the MOSTLYCLEANDIRS variable.

Therefore, if after '../configure; make dup.o' I find empty build
directories, I would find it quite annoying.

> How about if we do these mkdirs at configure-time, instead of at 
> build-time, like Emacs is already doing?

I think that mixes up the steps of configuration and build.
The GNU standards [2] describe configuration as

  The 'configure' script must
  record the configuration options so that they affect compilation.

Considering the creation of empty directories as part of "recording
the configuration" is quite far-fetched to me.


An alternative approach that would be OK with me would be that we
find out conditions (known at gnulib-tool invocation time or at
configure time at the latest) which make the

        $(MKDIR_P) '%reldir%' && \

lines redundant, and then use AC_SUBSTed variable to omit these lines:

@NMD@   $(MKDIR_P) '%reldir%' && \

NMD would be '' if --automake-subdir has been specified, '#' otherwise.
That's a simple optimization for the frequent case.

Bruno

[1] info standards, node "Standard Targets"
[2] info standards, node "Configuration"






reply via email to

[Prev in Thread] Current Thread [Next in Thread]