Re: if vs. ifdef in Makefile.am
Bogdan wrote: [...] Probably Nick's suggestion (a new option to ./configure or the AC_HEADER_ASSERT macro) would be the most future-proof, but it requires running ./configure each time you wish to change the build type (which maybe is not a bad idea, it depends). That would probably be a very good idea, to avoid mixing files built for one mode with files built for another. Even easier: use separate build directories for each type, from a common source directory, like so: $ : ... starting one directory above the source tree in ./src/ ... $ (mkdir test-build; cd ./test-build && ../src/configure --enable-assert ...) $ (mkdir release-build; cd ./release-build && ../src/configure --disable-assert ...) Now you avoid conflating modules for test and release builds and ending up with an executable that you cannot reliably replicate. A simple flag to make is unlikely to be properly recognized as a dependency for all objects built. -- Jacob
Re: rhel8 test failure confirmation?
Hi Frédéric, While building the trunk directly led to check failures, Confirmation is good. rebuilding the RPM in a mock environment didn't. Puzzling. I'll likely spend more time next week to perform more testing. It may simply be an environment problem: I guess it's possible, though I've tried make check in quite a few different environments by now (latest tools, distro tools, minimal env, maximal env, different kinds of filesystems, etc.), and the make check failures have persisted in all cases. Also, I'd expect an environment issue to cause a test (say, nodef.sh) to consistently succeed or consistently fail. But what I observe is a "probabilistic" failure. If I run nodef on its own 10 times, it might fail 7 times and succeed 3 times, say. Or 6/4 or 8/2 or 5/5 or whatever. That smells like a caching bug somewhere to me. But ... another friend tried make check on a freebsd system and *also* got failures (more or less the same set of failing tests, including nodef.sh). So evidently it's unlikely to be a low-level kernel/disk subsystem timing or caching bug. I'll likely spend more time next week to perform more testing. For sure, any digging will be greatly appreciated! --thanks, karl.
bug#59288: close 59288
Thanks Ilmari, thanks Jan. Closing.
Re: if vs. ifdef in Makefile.am
Hi, Is there a way, in Makefile.am, to check if a variable is empty or defined on command line. # Makefile.am if $(FOOBAR) --- $ make FOOBAR=1 Thanks
Re: if vs. ifdef in Makefile.am
Hi,
I observed that it adds `NDEBUG` in `config.h`. I will need to include this
`config.h`, right?
// config.h
#define NDEBUG 1
My current solution is like the following. I do not know if it can be
simplified.
# src/configure.ac
AC_ARG_ENABLE(
[ndebug],
[AS_HELP_STRING([--enable-ndebug],
[ndebug means release and turns off assert])],
[enable_ndebug=yes]
)
AM_CONDITIONAL([NDEBUG], [test x$enable_ndebug = xyes])
---
# src/main/Makefile.am
if NDEBUG
CPPFLAGS += -DNDEBUG
CFLAGS += -O3 # .cpp
else
CFLAGS += -g # .cpp
LDFLAGS += -fsanitize=address
endif
---
// src/main/main.c
void handlerCont(int signum){
printf("SIGCONT %d\n", signum);
#ifndef NDEBUG
__lsan_do_recoverable_leak_check();
#endif
}
Re: rhel8 test failure confirmation?
Hello, For the record, I made a first run of testing on a rhel 8 system. While building the trunk directly led to check failures, rebuilding the RPM in a mock environment didn't. I'll likely spend more time next week to perform more testing. It may simply be an environment problem: I noticed the RPM buildrequires weren't enough to execute bootstrap, there may be more to that. Frédéric Bérat Red Hat - Platform Tools https://www.redhat.com On Wed, Mar 1, 2023 at 10:55 PM Karl Berry wrote: > FAIL: t/remake-aclocal-version-mismatch.sh > > Thanks for trying it, Nick. > I'm glad it's not just me. > And I sure wonder wtf is going on :(. -k > >
bug#59288: close 59288
Jan Engelhardt discovered this is not a problem in automake, but in curl: https://lists.gnu.org/archive/html/automake/2023-03/msg00010.html Ilmari
Re: curl's XC_AMEND_DISTCLEAN (Seeking contractor for a regression bug fix)
On 2.3.2023 17.12, Jan Engelhardt wrote:
On Thursday 2023-03-02 09:56, Ilmari Lauhakangas wrote:
last year I reported a regression in automake:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59288
To the best of my knowledge, automake only runs during `autoreconf`,
but not during ./configure. So this looks less like an automake bug.
I also notice:
- big makefile with ./configure (as in the report)
- normal-sized makefile when I run ./config.status
So configure does more than config.status, as evidenced from stdout:
root@a4:~/curl# ./config.status
config.status: creating Makefile
...
config.status: creating packages/vms/Makefile
config.status: creating curl-config
config.status: creating libcurl.pc
config.status: creating lib/curl_config.h
config.status: lib/curl_config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
root@a4:~/curl#
# ./configure
...
config.status: creating packages/vms/Makefile
config.status: creating curl-config
config.status: creating libcurl.pc
config.status: creating lib/curl_config.h
config.status: lib/curl_config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
configure: amending lib/Makefile
configure: amending src/Makefile
configure: amending tests/unit/Makefile
configure: amending tests/server/Makefile
configure: amending tests/libtest/Makefile
configure: amending docs/examples/Makefile
configure: Configured to build curl/libcurl:
One will find that there is a file m4/xc-am-iface.m4 and a m4 macro
"XC_AMEND_DISTCLEAN". Whatever this is - the git log and the macro comment are
not useful:
dnl This macro performs shell code embedding into
dnl configure script in order to modify distclean
dnl and maintainer-clean targets of makefiles which
dnl are located in given list of subdirs.
but whatever it does, it causes the 682x duplication you see.
So it's a curl problem. Here's a patch.
From 74fa25bb5817f38c36c71820731eede6bc3be311 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt
Date: Thu, 2 Mar 2023 16:08:22 +0100
Subject: [PATCH] build: ditch the use of XC_AMEND_DISTCLEAN
This messes up the distclean targets in automake 1.16.
It's unclear what XC_AMEND_DISTCLEAN is supposed to fix
in the first place, all the more reason to remove it.
---
configure.ac | 2 --
1 file changed, 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 276c78474..988183d5d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4665,8 +4665,6 @@ AC_OUTPUT
CURL_GENERATE_CONFIGUREHELP_PM
-XC_AMEND_DISTCLEAN([lib src tests/unit tests/server tests/libtest docs/examples])
-
AC_MSG_NOTICE([Configured to build curl/libcurl:
Host setup: ${host}
That's amazing! I verify that your change fixes the issue for me,
testing with curl configure after 'autoreconf -fi'.
Would you like to submit it to curl upstream?
As I started this with a contracting proposal, let me know if you have
any requests, like a donation target or something.
Regards,
Ilmari Lauhakangas
Re: curl's XC_AMEND_DISTCLEAN (Seeking contractor for a regression bug fix)
On Thursday 2023-03-02 16:12, Jan Engelhardt wrote: >On Thursday 2023-03-02 09:56, Ilmari Lauhakangas wrote: >> last year I reported a regression in automake: >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59288 > >One will find that there is a file m4/xc-am-iface.m4 and a m4 macro >"XC_AMEND_DISTCLEAN". Whatever this is - the git log and the macro comment are >not useful[...] So I had only read XC_AMEND_DISTCLEAN_BODY. The real deal is a bit further down below. >dnl distclean and maintainer-clean targets are modified >dnl to avoid unconditional removal of dependency subdirs >dnl which triggers distclean and maintainer-clean errors > >dnl New behavior first removes each dependency tracking >dnl file independently, and only removes each dependency Since the previously identified automake commit 08849db866b44510f6b8fd49e313c91a43a3dfd3 stopped the removal of dependency subdirs, calling XC_AMEND_DISTCLEAN to replace said subdirs by individual files indeed would no longer necessary.
Re: if vs. ifdef in Makefile.am
ljh via Discussion list for automake , Wed Mar 01
2023 19:50:56 GMT+0100 (Central European Standard Time)
Hi community,
I want to build debug or release with
```
$ make # NDEBUG=1
$ make NDEBUG=1
```
Can I have automake.am to define and convey something like this to the output
Makefile:
```
ifdef NDEBUG # if vs. ifdef
CPPFLAGS += -DNDEBUG
CFLAGS += -O3 # .cpp
else
CFLAGS += -g # .cpp
LDFLAGS += -fsanitize=address
endif
```
But it seems I can only write `if` but not `ifdef` in Makefile.am.
So I had to enable ndebug option in configure.ac. That's a lot more work.
Thanks
Hi.
Just adding my 2 cents...
I hope I won't be saying something silly or obvious here, but maybe
you can pass the actual flags on the command line as a new variable
and include it *unconditionally* in the Makefile.am (expanding to
empty if not defined).
Sure, that's more troublesome, but at least you can have this
working even now, I guess.
# Makefile.am:
AM_CPPFLAGS = ... $(MY_CPPFLAGS) ...
AM_CFLAGS = ... $(MY_CFLAGS) ...
AM_LDFLAGS = ... $(MY_LDFLAGS) ...
A single 'autoreconf'/'automake' invocation later and you can do:
# release build:
make MY_CFLAGS=-g MY_LDFLAGS=-fsanitize=address
# debug build:
make MY_CFLAGS=-O3 MY_CPPFLAGS=-DNDEBUG
Probably Nick's suggestion (a new option to ./configure or the
AC_HEADER_ASSERT macro) would be the most future-proof, but it
requires running ./configure each time you wish to change the build
type (which maybe is not a bad idea, it depends).
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Soft(EN): http://bogdro.evai.pl/soft http://bogdro.evai.pl/soft4asm
www.Xiph.org www.TorProject.org www.LibreOffice.org www.GnuPG.org
Re: curl's XC_AMEND_DISTCLEAN (Seeking contractor for a regression bug fix)
On Thursday 2023-03-02 09:56, Ilmari Lauhakangas wrote:
> last year I reported a regression in automake:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59288
To the best of my knowledge, automake only runs during `autoreconf`,
but not during ./configure. So this looks less like an automake bug.
I also notice:
- big makefile with ./configure (as in the report)
- normal-sized makefile when I run ./config.status
So configure does more than config.status, as evidenced from stdout:
root@a4:~/curl# ./config.status
config.status: creating Makefile
...
config.status: creating packages/vms/Makefile
config.status: creating curl-config
config.status: creating libcurl.pc
config.status: creating lib/curl_config.h
config.status: lib/curl_config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
root@a4:~/curl#
# ./configure
...
config.status: creating packages/vms/Makefile
config.status: creating curl-config
config.status: creating libcurl.pc
config.status: creating lib/curl_config.h
config.status: lib/curl_config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
configure: amending lib/Makefile
configure: amending src/Makefile
configure: amending tests/unit/Makefile
configure: amending tests/server/Makefile
configure: amending tests/libtest/Makefile
configure: amending docs/examples/Makefile
configure: Configured to build curl/libcurl:
One will find that there is a file m4/xc-am-iface.m4 and a m4 macro
"XC_AMEND_DISTCLEAN". Whatever this is - the git log and the macro comment are
not useful:
dnl This macro performs shell code embedding into
dnl configure script in order to modify distclean
dnl and maintainer-clean targets of makefiles which
dnl are located in given list of subdirs.
but whatever it does, it causes the 682x duplication you see.
So it's a curl problem. Here's a patch.
>From 74fa25bb5817f38c36c71820731eede6bc3be311 Mon Sep 17 00:00:00 2001
From: Jan Engelhardt
Date: Thu, 2 Mar 2023 16:08:22 +0100
Subject: [PATCH] build: ditch the use of XC_AMEND_DISTCLEAN
This messes up the distclean targets in automake 1.16.
It's unclear what XC_AMEND_DISTCLEAN is supposed to fix
in the first place, all the more reason to remove it.
---
configure.ac | 2 --
1 file changed, 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 276c78474..988183d5d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4665,8 +4665,6 @@ AC_OUTPUT
CURL_GENERATE_CONFIGUREHELP_PM
-XC_AMEND_DISTCLEAN([lib src tests/unit tests/server tests/libtest
docs/examples])
-
AC_MSG_NOTICE([Configured to build curl/libcurl:
Host setup: ${host}
--
2.39.2
Seeking contractor for a regression bug fix
Hello, last year I reported a regression in automake: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59288 It is hitting some of our new LibreOffice contributors quite hard. I am working for The Document Foundation as a mentor through my one-man company, so I thought it would make sense for me to pay an automake developer to fix the issue. Let me know privately, if you are interested. Regards, Ilmari Lauhakangas
Re: if vs. ifdef in Makefile.am
On 2/3/23 16:07, ljh via Discussion list for automake wrote: Hi, It seems I can not use `--disable-assert` on Debian 11. You need to call macro AC_HEADER_ASSERT in your 'configure.ac' https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.71/autoconf.html#Particular-Headers hope that helps, Peter
