On Saturday, October 29, 2016 7:09:35 PM CET Pádraig Brady wrote:
> On 27/10/16 20:19, Pádraig Brady wrote:
> > On 27/10/16 17:09, Pavel Raiskup wrote:
> >> On Thursday, October 27, 2016 3:23:25 PM CEST Pádraig Brady wrote:
> >>> On 24/10/16 17:35, Florian Weimer wrote:
> >>>> I recall some reports that configure scripts are really slow in recent
> >>>> Fedora versions due to pervasive use of BIND_NOW.
> >>>>
> >>>> Has anyone investigated this further? Is there a bug report somewhere?
> >>>
> >>> Related to this I was wondering if there was any thought
> >>> to providing distro wide config.cache file that was primed with
> >>> results from base system libs and enabled with the rpm %{configure} macro?
> >>
> >> What set of defaults would be in system-wide config.cache file? Would you
> >> generate config.cache only for "minimal" buildroot?
> >
> > That would work. Even one generated per glibc build would suffice.
> > Priming per minimal buildroot it would help Fedora,
> > though it might also be useful to distribute the cache for users.
>
> This might also be achieved through the site defaults mechanism:
> https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Site-Defaults.html
Yeah, but important point to tell here is that we explicitly disable
config.site ATM in koji, because there's already the "default" config.site
for /usr prefix packaged in autoconf (basically implementing the
convenience dance with lib vs lib64 for "end user"). And that's not
something we want in koji, where we mostly depend on %configure macro.
The other issue is that config.site is bound to (single) specific
--prefix.
Theoretically, there would be those options with config.site:
o packaging the file separately from autoconf, but it sounds unrealistic
we'll have package which gets updates as often as cache needs to be
updated ..
o replace that file in koji
- When to do this? After package is tagged "stable"? Which package?
- solves koji builds, doesn't solve user's issues
o add something like this into config.site
'for i in /usr/share/config.site.dir/*
do
. /usr/share/config.site.dir/gcc 2>/dev/null || true
done'
But it seems like "performance" is not the issue in koji build system, so
we wouldn't enable this anyway (if there was even small chance of false
positive cache hit).
I'm not sure, if there was something like "runtime" configuration which
configure script could use, that should be probably something new developed in
Autoconf -- something which *-devel packages could create files for so packagers
could "pre-create" the cache files (or ideally autoconf could have also feature
pre-creating 'make install'able caches). Something like this could be enabled
both for koji and for user.
Pavel
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
