Re: [PATCH] Makefile: avoid undefined variables

[Chet Ramey]

On 10/25/24 8:44 AM, Martin D Kealey wrote:

> I've been looking at the Makefiles as well, and I find I have a lot of
> questions, like:
>
>     1. What is the point of ‘$(BUILD_DIR)’?

Just what it seems: an absolute pathname to the current build directory,
which can include spaces.


>     2. Do any of the following *ever* change?

Shorthand.

>     dot = .
>     DEFDIR = builtins
>     LIBBUILD = lib
>     GLOB_LIBDIR = lib/glob
>     INTL_LIBDIR = lib/intl
>     ALLOC_LIBDIR = lib/malloc
>     RL_LIBDIR = lib/readline
>     HIST_LIBDIR = lib/readline *(again)*

The history library is distributed as part of readline. You can build bash
with history and without readline.

>     SH_LIBDIR = lib/sh
>     TERM_LIBDIR = lib/termcap
>     TILDE_LIBDIR = lib/tilde


>     3. Are any of these *ever* used?

Some of these can be removed. Others you could have discovered with a
little work. But let's go through some of them.

>     ALLOC_ABSSRC = ${topdir}/$(ALLOC_LIBDIR)

There are ABSSRC and SRC variables for all the subdirectories.

>     EXTRASOURCES = *(a long list)*

This is from gettext.

>     GCC_LINT_CFLAGS = $(BASE_CCFLAGS) $(CPPFLAGS) $(GCC_LINT_FLAGS)

`make lint'

>     HIST_INCLUDEDIR = @HIST_INCLUDEDIR@

You can build bash against an already-installed history library (and
readline, too).

>     LIBINTL = @LIBINTL@
>     LTLIBINTL = @LTLIBINTL@

You don't have to build the included libintl from gettext; configure
decides and sets this appropriately.


>     OTHERS = *(a list)*

From gettext.

>     PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
>     PACKAGE_NAME = @PACKAGE_NAME@
>     PACKAGE_STRING = @PACKAGE_STRING@
>     PACKAGE_TARNAME = @PACKAGE_TARNAME@

For pkgconfig.

>     PSIZE_SOURCE    = *(a long list)*

Two entries is long? Anyway, the build process uses these to
determine the pipe size.

>     READLINE_OBJ    = *(a long list)*
>     RELOCATABLE_DEFS = -DENABLE_RELOCATABLE=1 -DIN_LIBRARY \

From gettext.

>     RL_INCLUDEDIR = @RL_INCLUDEDIR@

You can use readline from outside the bash source tree.

>     SIGNAMES_SUPPORT = $(SUPPORT_SRC)mksignames.c

The source for SIGNAMES_O.


>     SRC = *(a short list)*
>     SRC1 =  man2html.c

The source for OBJ1.

>     STUB_SOURCE = stub.c

Back when you could build a malloc library without the bash malloc, but
with alloca.

>     USE_INCLUDED_LIBINTL = @USE_INCLUDED_LIBINTL@

Just informational. You don't have to use the included lib/intl.

>     datarootdir = @datarootdir@

https://www.gnu.org/prep/standards/html_node/Directory-Variables.html#Directory-Variables

>     host_cpu = @host_cpu@
>     host_vendor = @host_vendor@

Come on.

>     l = @INTL_LIBTOOL_SUFFIX_PREFIX@
>     transform = @program_transform_name@

From gettext.

> I'm guessing that the idea was that you could link with a different version
> of the library outside the build tree (and outside the source tree), but is
> that actually used anywhere?

Yes, of course. Distros link bash against a system readline all the time.
There is lots of machinery in configure to make this work.

> If it *is* used, I'd ideally like to see all the variables that reference
> build directories have trailing slashes, unless they're completely empty
> (meaning the current directory). This would probably need some adjustment
> to the ‘configure’ script, or to autoconf.

What purpose would this serve?

> Otherwise I'd rather just hard-code them as relative paths; I have a patch
> to that effect if you're interested.

You'd be removing a documented feature that lots of people and distros use.
At least look at `configure --help' for what's available.


> Secondly, where targets are built by running a command in another
> directory, that secondary build process can inherit paths that no longer
> point to the correct place.

Provide an example so I can fix it if it's a problem.

> The tricky part is that this may or may not affect variables that point to
> the source, depending on how ‘configure’ was invoked:
>
>     - when run in the source tree as ‘./configure’ it sets ‘BUILD_DIR=.’
>     (which I would like to see changed to ‘./’ or empty);
>     - when run as ‘../bash-source/configure’ it sets
>     ‘BUILD_DIR=../bash-source’
>     - when run as ‘/home/me/src/bash/configure’ it sets
>     ‘BUILD_DIR=/home/me/src/bash’

No, it doesn't. BUILD_DIR is always set using `pwd`. You might be thinking
of srcdir or topdir.

> It might be tempting to thing "always use absolute paths", but that causes
> its own problems:
>
>     - it won't work in a sandpit where the current user does not have
>     permission to reach $PWD from ‘/’;

If this were an issue affecting people who build bash, someone would have
reported it by now. I don't think this is a big deal right now.

>     - some of the paths wind up being embedded in the resulting executable,
>     and they may contain sensitive information such as a personal username or
>     home directory;

Like what? Show an example. I don't see any paths from the source or
build directories in the executable.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

OpenPGP_signature.asc
Description: OpenPGP digital signature