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 c...@case.edu http://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
