Re: How to get autoconf to respect CC="gcc -std=c89"?

other problem. The problem is that Autoconf is defeating the recipient's freedom to select the compilation settings used. The person who is compiling the software should be able to specify the parameters to use used. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http

Re: How to get autoconf to respect CC="gcc -std=c89"?

to optionally compile the code for a particular C version without editing configure.ac. The developer may prefer to use the Autoconf default. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org

Re: AC_SYS_LARGEFILE

/20010703085350/http://ewe3.sas.com/standards/large.file/ Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: INSTALL nits

cts might be convinced to use a standard name. But most consumers of Autoconf are not GNU projects. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simples

Re: INSTALL nits

hey execute arbitrary scripts, but at least they are usually released in a way which allows them to be validated. Any generic instructions should make the user aware of these issues. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMag

Re: parallelization of ./configure compiler test processes

e residing in a co-process or a file-based database) to store known results and a fast hashing strategy to identify when inputs are the same as a known result. It would only help if the cache-lookups are less expensive than the actual tests. Bob -- Bob Friesenhahn bfrie...@simple.dallas.t

Re: parallelization of ./configure compiler test processes

that a "compiler" test should be cacheable given the same compiler with similar options. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems

Re: Possible regressions with trunk autoconf (vs 2.71)

(presumably at Github) in case he is busy. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: How can Autoconf help with the transition to stricter compilation defaults?

of compiler-specific behavior. If Autoconf is able to help, then the convoluted code can be in just one place (in Autoconf). Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: How can Autoconf help with the transition to stricter compilation defaults?

with it. The only reassurance is that GCC/Clang authors can not do what they want to do without providing a means for Autoconf and other similar test-based systems to work as is since Autoconf is so important. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen

Re: Parallelization of shell scripts for 'configure' etc.

educed and configure will run faster. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Detecting gated functions w/ AC_CHECK_FUNCS()

ght not be possible to support more than one ABI at a time. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: libtool-2.4.7 released [stable]

is a very strange decision which I have only seen before for OpenSSH. This is a way to verify using openssl: openssl sha256 -binary libtool-2.4.7.tar.gz | base64 Is there a GNU tool which can do this? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen

Re: Wrong order of preprocessor and compiler flags

think autoconf should be fixed. It does feel more logical. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: portability of xargs

On Tue, 15 Feb 2022, Paul Smith wrote: On Tue, 2022-02-15 at 15:37 -0600, Bob Friesenhahn wrote: I have been told by several people (who have much more self-esteem than me) that a build tool called 'cmake' is far more portable than Autotools so maybe we should make support for 32 year old

Re: portability of xargs

install older GNU software first in order to bootstrap sufficiently to a sufficient level of POSIX compliance. The well-built systems I bought prior to 2007 are already dead or difficult to repair. I do not see any reason to spend any time at all supporting an OS older than 2008. Bob -- Bob

Re: portability of xargs

with directory paths which contain a space and they need to take additional administrative measures in order to provide directory paths which work with Autotools. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer

Re: abs_top_srcdir broken?

;; *) my_abs_top_srcdir=`pwd`/$srcdir ;; esac GraphicsMagick does this to get a full path to the top of the source tree: srcdirfull="`cd $srcdir && pwd`" Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick M

Re: Checking failing dlopen when building 32bit software

if you get 32-bit support working today on your Linux distribution that it might not work in the next major release cycle. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: automake problem with multiple "-rpath"

posting to the GNU 'automake' list, although this could possibly be a libtool problem and thus an issue for discussion on the 'libtool' list. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org

Re: How to "bake in" configure args

On Wed, 24 Mar 2021, Dan Mahoney (Gushi) wrote: On Tue, 23 Mar 2021, Bob Friesenhahn wrote: On Tue, 23 Mar 2021, Dan Mahoney (Gushi) wrote: Is there a "standard" way to do this? Google kind of fails for this. I see that Gavin Smith already answered the question

Re: How to "bake in" configure args

-lfreetype -ljpeg -lpng16 -lwmflite -lX11 -llzma -lz -lzstd -lm -lpthread From the above, it can be seen what values were determined for standard Autoconf/Automake build variables (e.g. AC_DEFINE_UNQUOTED). This is all done by using Autoconf defines suitable for including in source code.

Re: libtool wrapper

s, or am I stuck creating some sort of fake chroot to test this. It seems that the project is not entirely using the Autotool's way of doing things. I suggest reading the Automake documentation first. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/user

Re: config.sub/config.guess using nonportable $(...) substitutions

lication's own configure.ac script) might as well be updated to use the less-portable yet more convenient modern syntax and this implies the ability to safely use other modern syntax as well. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ Grap

Re: Automake's file locking

. This is done via a '.NOTPARALLEL: target' type declaration. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

GM/aclocal.m4] Error 1 In my case there is only one active developer so there would not be actual corruption. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.sim

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

* have something to do. It might be Perhaps this experience is a side effect of my recent experience (regarding AC_INIT and versioning) and not the normal case. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

purpose. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Parallel configure

On Thu, 28 Jan 2021, Zack Weinberg wrote: On Mon, Jan 25, 2021 at 5:42 PM Bob Friesenhahn wrote: The challenge here is that a considerable part of configure scripts depend on decisions which were made before. There is no dependency information currently in configure scripts. Yes

Re: Future plans for Autotools

sequential. The challenge here is that a considerable part of configure scripts depend on decisions which were made before. There is no dependency information currently in configure scripts. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen

Re: Future plans for Autotools

much rather write (and maintain) two lines of automake code than even a single page of GNU make code. Even more importantly, you already wrote those two lines of Automake code! :-) The Makefile.am format is a sort of "contract" which is assumed by Automake users. Bob -- Bob Friesen

Re: Future plans for Autotools

be found without much effort. Yes, it might have been as much as 10 years already, but surely not that much has changed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key

Re: Automake's file locking (was Re: Autoconf/Automake is not using version from AC_INIT)

not provide a 'maintainer mode' to stop maintainer rules from firing, then this could impact archaic targets from the early '90s. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key

Re: Autoconf/Automake is not using version from AC_INIT

On Sun, 24 Jan 2021, Paul Eggert wrote: On 1/23/21 4:06 PM, Bob Friesenhahn wrote: A tiny fork/exec is not a big deal. It is indeed not a big deal. That being said, one can optimize away GNU make's fork and exec by using "@:" instead of "@true". At the moment it

Re: Autoconf/Automake is not using version from AC_INIT

On Sun, 24 Jan 2021, Zack Weinberg wrote: On Sun, Jan 24, 2021 at 7:27 PM Bob Friesenhahn wrote: AC_SUBST([CONFIGURE_DEPENDENCIES],["$CONFIGURE_DEPENDENCIES \$(top_srcdir)/ChangeLog \$(top_srcdir)/version.sh"]) Why did you write it like this instead of CONFIGURE_DE

Re: Autoconf/Automake is not using version from AC_INIT

On Mon, 25 Jan 2021, Peter Johansson wrote: Hi Bob, On 24/1/21 10:06 am, Bob Friesenhahn wrote: I did try this type of solution.  As I recall, it did not help because the terminal target is Automake's regeneration rules, which are apparently optimized to not modify the target files (e.g

Re: Autoconf/Automake is not using version from AC_INIT

for a side project. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf/Automake is not using version from AC_INIT

he Automake project won't just pull the rug out from under me. I was hoping to make the project more robust against existing deprecation threats in case I don't survive, but it looks like I did not succeed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simple

Re: Future plans for Autotools

ake) before starting. The implementation of Autoconf is over-burdened with syntax. It contains more "syntax" than anything else I have ever seen. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMa

Re: Future plans for Autotools

underlying implementation changes. The support for 'distcheck' is excellent. Regardless, thanks for your ideas and the red alert. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key

Re: Autoconf/Automake is not using version from AC_INIT

PENDENCIES],['$(top_srcdir)/ChangeLog $(top_srcdir)/version.sh']) If the version stamp info came from git or hg, then intermediate generated files would surely be required. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintaine

Re: Autoconf/Automake is not using version from AC_INIT

tamp does not get updated, it will produce this noise, and if does get updated, then there is a whole reconf-config-build cycle. Is there any solution for that? Otherwise I have a less fancy means which works without the extra noise. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://w

Re: Autoconf/Automake is not using version from AC_INIT

as much of the original developer's powers as possible. Once again, thanks for the helpful advice. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org

Re: Autoconf/Automake is not using version from AC_INIT

has changed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Autoconf/Automake is not using version from AC_INIT

at Autoconf itself, I see dreadful looking things such as an extra GNUmakefile and targets which create hidden files which go into the tarball. If this sort of thing is necessary, then I will revert my few days of work. Thanks, Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http

Re: AC_INIT produces unexpected "PACKAGE" and "VERSION" strings in config.h

tions)" I am not sure what the value of adding another redundant definition is but it seems that is what Automake decided to do. The problem is that I have a subordinate package which also uses VERSION but the definition is not the same. Bob On Tue, 5 Jan 2021, Bob Friesenhahn wrote: I

AC_INIT produces unexpected "PACKAGE" and "VERSION" strings in config.h

"GraphicsMagick" /* Version number of package */ #define VERSION "1.4.020210102" These definitions are unexpected. What produces these definitions and how can I get rid of them? Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ Graph

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

Follow-up Comment #11, sr #110403 (project autoconf): I see that https://www.illumos.org/issues/13405 addresses updating Illumos ksh93 to a recent version. The description says that the task is 'hard' but the task is showing progress made. Regardless, a note about the bug is certainly useful

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

the recommended AC_INT strategy is not without some danger since it is more rigid than the previous shell-variable based approach. This is particularly the case for the project version and how the project version is applied when creating the tarball. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

to be used and included in spite of the Automake options provided. While I see more detail sprinkled around the generated files, it seems that this COPYING file may be the biggest issue. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

9,675,006 to 9,683,225 bytes (8,219 bytes difference when compressed). Perhaps it is not much but the size difference seems large given that only 23 lines of original source code were added. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen

Re: Getting srcdir in script executed using m4_esyscmd in AC_INIT

urcing the script is ok but not if it does not compute the same values. Thank you for your help. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.

Getting srcdir in script executed using m4_esyscmd in AC_INIT

and m4_esyscmd, I do not know how to obtain the path to the top of the source directory. Can someone please give me a clue as to how to determine the top of the source directory? Thanks, Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen

Re: Autoconf version number after 2.70

herd" on a herd that does not exist. Dealing with change and multiple options is hard so keep things simple for us users. The simple approach is to keep doing what worked fine before. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ Grap

Re: [sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

annoying to me and it seems irrelevant. There is no need to diminish a viable free operating system. In a similar spirit, I should point out that Illumos is doing better than CLISP according to trends.google.com since the limited popularlity is stable and not dwindling. ;-) Bob -- Bob Friesenhahn

[sr #110403] autoconf-2.70 trips bug in here-doc handling in OmniOS /bin/sh

Follow-up Comment #9, sr #110403 (project autoconf): Since the shell delivered with OmniOSce is provided by Illumos, the appropriate bug tracker would be at https://www.illumos.org/projects/illumos-gate/issues ___ Reply to this item at:

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

Follow-up Comment #6, sr #110403 (project autoconf): I wonder why autoconf-2.69b does not exhibit the issue, and in fact I have not seen any other issues with configure scripts on this system? This system has been one of my core development systems for quite some time now. Note that this system

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

Follow-up Comment #4, sr #110403 (project autoconf): I just verified that this test passes for autoconf-2.69b. This is the test result using autoconf-2.69b, which is what I had tested on this system previously: ## - ## ## Test results. ## ## - ## 474 tests behaved as

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

Follow-up Comment #3, sr #110403 (project autoconf): The external host name appears to be "IP65-66-246-71.simplesystems.org". Sorry for not making it more memorable in DNS. Previously we determined that the ksh93-based shell behaves poorly if /usr/xpg4/bin is in the path. So I removed it from

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

Additional Item Attachment, sr #110403 (project autoconf): File name: autoconf-2.70-test537.tar.gz Size:905 KB ___ Reply to this item at:

Re: Request to revert the C version change

, something does not feel right so I will pass on using this release of Autoconf for software releases. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http

[sr #110403] autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS

URL: Summary: autoconf-2.70 AC_TYPE_INTMAX_T test failure under OmniOS Project: Autoconf Submitted by: bfriesen Submitted on: Wed 16 Dec 2020 02:40:22 PM CST Category: None

Re: Hidden files in autoconf 2.70 distribution?

-version" in the autoconf 2.70 release tarball.) -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Hidden files in autoconf 2.70 distribution?

seems like the GNU coding standards should be addressing such things. The files appeared in autoconf-2.69c and were not in autoconf-2.69b. Files starting with a '.' are treated as hidden according to Unix conventions, but not typically on operating systems not adhering to Unix conventions.

Hidden files in autoconf 2.70 distribution?

I notice that the autoconf-2.70 tarball contains "hidden" files. Is this intentional? The "hidden" files are ".prev-version", ".version", and ".tarball-version". Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesys

Re: [PATCH] similar treatment for CYGWIN and MSYS2

er whereas Cygwin and MSYS provide a compiler plus a rather-similar Unix-like run-time environment. I recommend against it. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key

Re: determine base type of a typedef

involving recent C standards should be avoided since it harms portability. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: verifying autoconf-2.69c.tar.xz.sig

nfig.guess and config.sub from a git repository using the pattern "https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=config/${file};hb=HEAD; I am trusting that the gnulib repository (and its gitweb front end) is inherently secure but without any proof of it. Bob -- Bob Fr

Re: autoconf-2.69c released [beta]

out what's wrong. These are Autoconf test suite failures. You should still have access to an OpenIndiana system since I see that you last accessed my OpenIndiana system on August 4th!. Access for yourself and Paul Eggert has not been taken away. Bob -- Bob Friesenhahn bfrie

Re: autoconf-2.69c released [beta]

__) fi fi I now have the GraphicsMagick configure script updated and apparently working fine locally with Autoconf 2.69c. There are still some deprecation warnings from an included m4 module. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfri

Re: autoconf-2.69c released [beta]

)dnl << const char *func=__func__; return (func != 0 ? 0 : 1); ]])],[changequote(, )dnl ac_cv_have_C__func__='yes'],[ac_cv_have_C__func__='no'])]) if test "$ac_cv_have_C__func__" = 'yes' ; then AC_DEFINE(HAS_C__func__,1,Define if C compiler supports __func__) fi fi Bob -- Bob

Re: autoconf-2.69c released [beta]

On Sun, 27 Sep 2020, Paul Eggert wrote: On 9/27/20 11:23 AM, Bob Friesenhahn wrote: Is 'autoupdate' supposed to be safe to use? I would never trust the output of 'autoupdate', no. It's meant to be suggestions and/or indications of problems, and is not meant to be authoritative. Perhaps

Re: autoconf-2.69c released [beta]

On Sun, 27 Sep 2020, Bob Friesenhahn wrote: A great many macros (still used to provide backward compatibility) are now declared as obsolete. I ran 'autoupdate' and see that AC_TRY_COMPILE statements were changed to use new syntax. The problem is that with the replacement code it inserted I

Re: autoconf-2.69c released [beta]

burden on my users. If the resulting output can not be used with the prevailing version (2.69) then I can not use it! I don't see now a new release can obviate the stable release which preceded it and is still in primary use! Under OpenIndiana I still get 6 test failures. Bob -- Bob

Re: Debian archive rebuild with Autoconf 2.69c

of the supported systems. My understanding is that it possible to initiate a 'pkgsrc' build of tens of thousands of packages in a single go. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public

Re: Warning category skew between Autoconf and Automake - workaround in autoreconf?

be required. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Autoconf bug reports gone missing?

10. Unfortunately, my Solaris 10 system is down with a failed CPU fan (and I have not been inspired to try to fix it yet) or else I could make it available. Testing on Illumos-based systems will not be the same as testing under Solaris 11. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us

Autoconf bug reports gone missing?

reports with testsuite.log files automatically discarded or are these reports pending moderation? Thanks, Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http

[GNU Autoconf 2.69b] testsuite: 329 failed

in the path. See the attached testsuite log file. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt testsuite.log.gz

Re: feedback on 2.69b

version, and it would be important that Autoconf respect such requests if they were supplied. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

' would arrange to execute configure under different available shells to make sure that the results are the same. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

to introduce a bash-specific shell function if it was only going to be executed by bash. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users

Re: debugging autoconf tests (was: gl_CACHE_VAL_SILENT)

control system works. This causes users to become afraid of Autotools. Anything which encourages users to not be afraid to build from source code (rather than depending on binary packages built by others) is useful to the future of free software. Bob -- Bob Friesenhahn bfrie

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

. Given C++ code with lots of templates, compiling is still surely the bottleneck. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

:11.71elapsed 106%CPU (0avgtext+0avgdata 71368maxresident)k 0inputs+31856outputs (0major+2007933minor)pagefaults 0swaps Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

algorithmic things like loops, but it was noticed to be slower at parsing large numbers of simple commands and Autoconf configure scripts are often almost 1MB of script. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

bly, then Autoconf's reputation will improve. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: M4sh tests 77 and 78 vs /bin/sh -> dash

had crept in and libtool was not ok on non-GNU/Linux systems until those non-portable artifacts were fixed. If Autoconf were to reqire GNU bash and GNU sed, and Automake were to require GNU make, and libtool were to require GNU binutils and GCC, then Autotools should become a historical artifact.

Re: Making Autoconf 2.70 happen in the near future

d is based on free software and that patches were submitted. Hopefully people using less popular systems have not given up on Autoconf and will notice this discussion. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintaine

Re: Making Autoconf 2.70 happen in the near future

by a patch? The git commits are more a factor of who has the personal ability to make commits than whether the commits are the most important changes needed. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http

Re: Android and iOS triplets are not recognized

. There is no reason to fail to recognize them after 10 years. Autoconf itself has not been released since 2012. This feels like a long time to me, although not quite a decade. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer

Re: No macro for C11/C18?

or C18, then there are likely to be unexpected failures. The test would need to be rigorous in order to detect such cases and fall back to the newest working version. If the software really does need such a new C standard vesion in order to work properly, then there is a problem. Bob -- Bob

Re: STDCXX issue

uses acx_pthread.m4 and so the aclocal.m4 file includes this line m4_include([m4/acx_pthread.m4]) Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http

Re: STDCXX issue

not be available installed on the system. Google appears to be a wealth of information on this topic. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org

Re: Autotools lint tool

On Sun, 6 Oct 2019, Richard Ash wrote: On Thu, 3 Oct 2019 17:06:18 -0500 (CDT) Bob Friesenhahn wrote: Many existing common tests found in Autoconf scripts can just be removed since standards have made them unnecessary. At the risk of being contrary, this is one of the things which

Re: Autotools lint tool

just be removed since standards have made them unnecessary. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: Check if a macro has already been defined with AC_DEFINE

stored in variables of the form "ac_cv_have_FOO". Check the generated config.status script for the exact name to test. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

Re: testsuite could basename the "Generated from"

think that this falls into the current trend that reproducible builds are a good thing. Anything which normalizes the output (even for temporary/transient files) seems like a good idea. The only exception is if it is necessary to know the origin and it is not intuitively obvious. Bob -- Bob

Re: Conventions on build variables

the GNU coding standards as well as the standard definitions documented in the GNU make manual will help quite a lot. The standard INSTALL text file documents many of these conventions. You will find available substitutions stored in the generated config.status script. Bob -- Bob Friesenhahn

Re: Conventions on build variables

details. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt ___ Autoconf

  1   2   3   4   5   6   >