On Thu, Mar 12, 2020 at 6:47 PM Michael Orlitzky wrote:
> On 3/12/20 4:53 PM, Zack Weinberg wrote:
> >
> > On further investigation, there is a concrete reason why autoconf 2.69
> > prefers SHELL=/bin/bash to SHELL=/bin/dash, namely that dash doesn't
> > support $LINENO, necessitating a complicate
On Thu, Mar 12, 2020 at 9:22 PM Paul Eggert wrote:
> On 3/12/20 1:53 PM, Zack Weinberg wrote:
> > the
> > changed behavior of autoconf trunk was not intentional; it's because
> > commit 2b59b6f8a79b8bf77e178ff4e5aa0ede433d39cf missed a direct use of
> > $as_echo in _AS_DETECT_BETTER_SHELL, causing
On Fri, Mar 13, 2020 at 11:31 AM Zack Weinberg wrote:
> FYI, I grepped the whole autoconf source tree and I didn't find any
> other uses of $as_echo. However, there is one use in
> libtool/tests/testsuite.at and one use in
> autoconf-archive/m4/ax_pthread.m4. I'm going to send patches to both
>
Bob Friesenhahn (2020/03/12 16:04 -0500):
> One reason why some projects are discarding use of Autoconf (and moving to
> CMake and Meson/Ninja) is due to how long it takes to execute a configure
> script. Given modern multicore CPUs, it often takes as much (or more) time
> to run the configure scr
On Fri, 13 Mar 2020, Sébastien Hinderer wrote:
Is the time spent in the shell such a big part of configure's total
execution time?
I am also wondering how widely config.status is known by non-experts. I
guess in the situation where the time spent ocnfiguring matters, e.g.
when you are developin
I am really not sure why the time output looks so funky but here are
some timings of the GraphicsMagick configure script using /bin/dash
and /bin/bash on an Ubuntu 18.04 LTS system. The timing difference is
not as much as I remember from years ago. The difference might be due
to configure
On 3/13/20 2:27 PM, Bob Friesenhahn wrote:
>
> /bin/dash
> 8.31user 2.37system 0:10.22elapsed 104%CPU (0avgtext+0avgdata
> 71316maxresident)k
> 0inputs+30016outputs (0major+1529930minor)pagefaults 0swaps
>
> /bin/bash
> 9.38user 3.07system 0:11.71elapsed 106%CPU (0avgtext+0avgdata
> 71368maxres
On Fri, 13 Mar 2020, Michael Orlitzky wrote:
I get similar results here, bash adds about a second. With large scripts
the improvement is lost in the noise, but it's still a free lunch.
When using a parallel compile on a modern multi-core system, I find
that from-scratch build timing (for Grap
I did experiment on two projects and didn't observe that noticeable
differences either.
Sébastien.
Hi Zack,
This plan is great news!
>I was hoping to get access to more “exotic”
>environments via the GCC Compile Farm, but all of their more
>interesting hosts are down as I write this. :-(
>
>I will cheerfully add to the above anything that someone is willing
>to give me an u
On Fri, Mar 13, 2020 at 5:35 PM Bruno Haible wrote:
> If you can delegate part of this testing, I'd be willing to help. I agree
> that setting up virtual machines or emulated build environments is time
> consuming (between 1 hour to 4 hours for each platform). But I've done so
> already in the pas
[CCing autoconf@gnu.org]
Hi Zack,
> Abstractly, the best thing to do about this would be to remove the
> macro and change all of its uses to be AC_CACHE_CHECK, with proper
> messaging, instead.
The point is that we don't want messaging for some tests. Most people
find the 'configure' output alre
Hi Bruno,
On 13/03/2020, Bruno Haible wrote:
> The underlying problem in Autoconf is the following: There is a macro
> AC_CACHE_CHECK that does messaging, and a macro AC_CACHE_VAL whose
> main purpose is to make a cache lookup, not messaging, but it
> nevertheless outputs '(cached)' strings occas
On 3/13/20 3:04 PM, Nick Bowler wrote:
AS_VAR_SET_IF([my_cv_no_printing], [my_cv_no_printing=hello])
I assume you meant
AS_VAR_SET_IF([my_cv_no_printing], [], [my_cv_no_printing=hello])
Nick Bowler and Paul Eggert wrote:
> >AS_VAR_SET_IF([my_cv_no_printing], [my_cv_no_printing=hello])
>
>AS_VAR_SET_IF([my_cv_no_printing], [], [my_cv_no_printing=hello])
But then I lose
- the various AC_DIAGNOSE checks that are in AC_CACHE_VAL,
- possible future improvements / changes
Hi,
Should autoconf build from tarball without help2man? I built a tarball
of git master with 'make dist' but when I attempt to build that on
another system it fails if help2man isn't present. Shouldn't this be a
requirement only for the git builds? 2.69 doesn't have this behaviour.
Cheer
On 3/13/20 3:42 PM, Ross Burton wrote:
Should autoconf build from tarball without help2man?
Yes, it should.
On Fri, Mar 13, 2020 at 5:54 PM Bruno Haible wrote:
>
> [CCing autoconf@gnu.org]
>
> Hi Zack,
>
> > Abstractly, the best thing to do about this would be to remove the
> > macro and change all of its uses to be AC_CACHE_CHECK, with proper
> > messaging, instead.
>
> The point is that we don't want
On 2020-03-13, Paul Eggert wrote:
> On 3/13/20 3:04 PM, Nick Bowler wrote:
>>AS_VAR_SET_IF([my_cv_no_printing], [my_cv_no_printing=hello])
>
> I assume you meant
>
>AS_VAR_SET_IF([my_cv_no_printing], [], [my_cv_no_printing=hello])
Yes, thank you for the correction.
Cheers,
Nick
On 3/13/20 8:31 AM, Zack Weinberg wrote:
Thanks for taking care of that. I wouldn't have been bold enough to
switch to sh -c. Out of curiosity, what was the historical reason for
echoing the string into the shell?
Originally it was a big here-document, so big that I guess they assumed
sh -c
Hi Zack,
> Yeah, most of the time
> that text is just going to scroll by unread, but when something goes
> wrong, the poor schmuck who has to debug it wants to know that it was
> the test for `ceil` (for instance) that hung the build, not the
> unrelated thing that happens to have been tested righ
21 matches
Mail list logo
