> My use case in Buildroot is very different: we build potentially
> several dozens of different software components, each time with a
> different toolchain/environment. So we're almost never rebuilding with
> the exact same configuration, and therefore using a cache doesn't
> really work for our u
Dear Rhys Ulerich,
On Fri, 6 Jun 2014 10:14:41 -0500, Rhys Ulerich wrote:
> Granted, configure time does add up if one builds 10s of packages in
> sequence. Is there some reason configure caches are unsuitable to
> gain speedup there? I see almost a six-fold configure improvement on
> grep-2.20
I should probably get the configure and build times re-measured for NTP.
Feel free to grab
http://www.eecis.udel.edu/~ntp/ntp_spool/ntp4/ntp-dev/ntp-dev-4.2.7p444.tar.gz
and see for yourself... it's a bit of a monster for something that's
about 200k LOC.
It would be great to see significant speed
Rhys Ulerich wrote:
Is there some reason configure caches are unsuitable to
gain speedup there?
I regularly build with experimental versions in which the 'configure'
tests themselves differ from run to run, and where configure caches
would give me incorrect results. So I never use caches.
On Fri, Jun 6, 2014 at 9:48 AM, Paul Eggert wrote:
> veerrry common for 'configure' to be an unreasonably large part of the build
> process
But is an unreasonably large part of a reasonably long build process?
You quote a from-scratch build with configure being an order of
magnitude slower than p
Rhys Ulerich wrote:
I only find the configure process to be frustratingly slow when run
against compilers with license keys or with checks accessing network
storage.
That's not my experience at all. Take the bleeding-edge version of GNU
grep, say, which I just now happened to be working on.
> Wouldn't it be time to
> think about moving autoconf to a more parallel logic, where N tests
> could run in parallel in sub-processes?
I only find the configure process to be frustratingly slow when run
against compilers with license keys or with checks accessing network
storage. Running those
Thomas Petazzoni wrote:
Wouldn't it be time to
think about moving autoconf to a more parallel logic, where N tests
could run in parallel in sub-processes?
It's long been past time to do that. Some technical problems need to be
solved, but the main problem is that nobody has volunteered to tak
Dear John Spencer,
On Sun, 23 Mar 2014 01:24:54 +0100, John Spencer wrote:
> there are many configure scripts out there that still check for things
> that are standard since at least 10 years, and doing this extensively
> and over and over (people building software themselves usually build
> m
Ralf Corsepius wrote:
On 03/23/2014 01:24 AM, John Spencer wrote:
and for posix
- sizeof int == 4
- have select()
- etc
These assumptions are unsafe, esp. on non-mainstream architectures/OSes,
which only partially implement c99.
E.g. it's not that uncommon to find toolchains for embedded pl
On 03/23/2014 01:24 AM, John Spencer wrote:
there are many configure scripts out there that still check for things
that are standard since at least 10 years, and doing this extensively
and over and over (people building software themselves usually build
more than one package) consumes a lot of ti
On 03/23/14 19:00, Russ Allbery wrote:
> Some of the problems with snprintf are also quite serious. For example,
> Solaris 9 (which I believe is otherwise C99-conforming) would return -1
> when given NULL, 0 as the first arguments to snprintf, which makes it
> impossible to use snprintf safely in
On Sun, 23 Mar 2014, John Spencer wrote:
i even ask myself sometimes if it is still worth plastering software and
configure scripts with checks and ifdefs for these broken platforms that
probably cant even build the dependencies of modern software (these ifdefs
are almost always completely un
On Sun, 23 Mar 2014, Bob Friesenhahn wrote:
> On Sun, 23 Mar 2014, John Spencer wrote:
> > having an option like --assume-c99 could provide a shortcut so all checks
>
> I don't like any approach which hard-codes assumptions in Autoconf. Hard-coded
> assumptions can easily be wrong and configure s
On Sun, Mar 23, 2014 at 12:24 AM, John Spencer
wrote:
> there are many configure scripts out there that still check for things that
> are standard since at least 10 years, and doing this extensively and over
> and over (people building software themselves usually build more than one
> package) con
Bob Friesenhahn wrote:
On Sun, 23 Mar 2014, John Spencer wrote:
there are many configure scripts out there that still check for things
that are standard since at least 10 years, and doing this extensively
and over and over (people building software themselves usually build
more than one packa
Russ Allbery wrote:
John Spencer writes:
having an option like --assume-c99 could provide a shortcut so all
checks like
- have stdint.h
- have snprintf()
- etc
These are un-alike, just to mention. A surprising number of platforms
have an snprintf function that's broken. To test it prope
John Spencer writes:
> having an option like --assume-c99 could provide a shortcut so all
> checks like
> - have stdint.h
> - have snprintf()
> - etc
These are un-alike, just to mention. A surprising number of platforms
have an snprintf function that's broken. To test it properly, you need
so
On Sun, 23 Mar 2014, John Spencer wrote:
there are many configure scripts out there that still check for things that
are standard since at least 10 years, and doing this extensively and over and
over (people building software themselves usually build more than one
package) consumes a lot of ti
there are many configure scripts out there that still check for things
that are standard since at least 10 years, and doing this extensively
and over and over (people building software themselves usually build
more than one package) consumes a lot of time (especially due to the
non-parallel nat
there are many configure scripts out there that still check for things
that are standard since at least 10 years, and doing this extensively
and over and over (people building software themselves usually build
more than one package) consumes a lot of time (especially due to the
non-parallel nat
21 matches
Mail list logo
