[PATCH] Makefile.in: add LIBINTL_H to install-headers
I'm not sure if this is the most idiomatic way to write the rule, but
if a libintl.h is generated, it needs to make it into the installed
headers directory to allow loadables to build.
---
Makefile.in | 4
1 file changed, 4 insertions(+)
diff --git a/Makefile.in b/Makefile.in
index 00db8cbb..83b51583 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -933,6 +933,9 @@ install-headers: install-headers-dirs
${INSTALL_DATA} $(srcdir)/"$$hf"
$(DESTDIR)$(headersdir)/$$hf || exit 1; \
fi ; \
done
+ @if test X$(LIBINTL_H) != X ; then \
+ $(INSTALL_DATA) $(LIBINT_H) $(DESTDIR)$(headersdir)/ || exit 1;
\
+ done
-$(INSTALL_DATA) $(SUPPORT_DIR)/bash.pc
$(DESTDIR)$(pkgconfigdir)/bash.pc
uninstall-headers:
@@ -940,6 +943,7 @@ uninstall-headers:
-( cd $(DESTDIR)$(headersdir)/include && $(RM) $(INSTALLED_INCFILES) )
-( cd $(DESTDIR)$(headersdir)/builtins && $(RM)
$(INSTALLED_BUILTINS_HEADERS) )
-( cd $(DESTDIR)$(headersdir) && $(RM) $(CREATED_HEADERS) )
+ -( cd $(DESTDIR)$(headersdir) && $(RM) libintl.h )
-( $(RM) $(DESTDIR)$(pkgconfigdir)/bash.pc )
uninstall: .made
--
2.47.0
[PATCH] bash.pc.in: use DEFS
If you try using Cflags from the generated pc file, presumably with
something like:
cc $(pkg-config --cflags bash) -c o myload myload.c
the compilation is likely to fail because HAVE_CONFIG_H is not defined.
---
support/bash.pc.in | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/support/bash.pc.in b/support/bash.pc.in
index 60096593..4de73120 100644
--- a/support/bash.pc.in
+++ b/support/bash.pc.in
@@ -8,9 +8,10 @@ libdir=@libdir@
loadablesdir=@loadablesdir@
headersdir=${includedir}/@PACKAGE_NAME@
+DEFS = @DEFS@
LOCAL_CFLAGS = @LOCAL_CFLAGS@
LOCAL_DEFS = @LOCAL_DEFS@
-CCFLAGS = ${LOCAL_DEFS} ${LOCAL_CFLAGS}
+CCFLAGS = ${DEFS} ${LOCAL_DEFS} ${LOCAL_CFLAGS}
CC = @CC@
SHOBJ_CC = @SHOBJ_CC@
--
2.47.0
Re: [PATCH] lib/readline/doc makefiles clean targets
On Thu, Nov 7, 2024 at 6:06 PM Chet Ramey wrote: > > On 11/4/24 9:44 AM, Mike Jonkmans wrote: > > > There are some issues though. Some less important. > > 1) After 'make distclean', it doesn't build: some .o files need y.tab.h. > > y.tab.h isn't part of the devel branch, you need bison to build it, and > it is included in the bash distributions. I see the problem here, though. > I'll figure out a way to fix it that's compatible with it being included > and not without too many release-specific changes. The latest change, +Makefile.in + - y.tab.h: move from CREATED_HEADERS to INSTALLED_HEADERS so we don't + clean it makes the install-headers target fail for an out-of-tree build since y.tab.h is in $(BUILD_DIR) but INSTALLED_HEADERS are only looked for in $(srcdir)
Re: "complete -o filenames" sometimes not working
On Mon, Nov 11, 2024 at 10:51 PM Grisha Levit wrote: > > If your goal is to have readline do the quoting for you > Yes this is what I want to do. > , without treating the completions as filenames, the next version of bash > (5.3, see the 'devel' branch in the git repo) will have the '-o fullquote' > option for compgen/compopt. > This is cool. Thanks. For now I'll still use the 2-pass escaping way as in https://lists.gnu.org/archive/html/bug-bash/2018-03/msg00137.html
Re: fg via keybind modifies tty settings
On 11/10/24 7:14 PM, Martin D Kealey wrote: Perhaps what's really needed is to make sure that "ordinary" commands bound using bash -x are completely broken (so people won't try to use them), rather than almost working. `Ordinary' commands aren't broken. Programs like vim that modify the terminal settings, which are in the minority, are. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] lib/readline/doc makefiles clean targets
On Thu, Nov 7, 2024 at 6:06 PM Chet Ramey wrote: > > If you find yourself in this sitution, it's easy enough to remove > parser-built and y.tab.c and run make again before I fix it. $ git clean -xfdq In MSYS2 on Windows, all the generated executables end in ".exe", which of course the .gitignore file doesn't ignore. I haven't even tried any kind of "make clean".
