Hi hackers, I'm sharing the rebased version of this patch, if you're still interested.
I would appreciate any feedback or concerns. Best, Melih Andrew Dunstan <and...@dunslane.net>, 9 Nis 2022 Cmt, 19:34 tarihinde şunu yazdı: > > On 4/8/22 21:02, Andres Freund wrote: > > Hi, > > > > On 2022-04-08 19:27:58 -0500, Justin Pryzby wrote: > >> On Thu, Apr 07, 2022 at 10:10:21AM -0700, Andres Freund wrote: > >>> On 2022-04-06 11:03:37 -0400, Andrew Dunstan wrote: > >>>> On 3/30/22 20:26, Andres Freund wrote: > >>>>> Could you try using dash to invoke configure here, and whether it > makes configure faster? > >>>> I got weird failures re libxml/parser.h when I tried with dash. See > >>>> <https://cirrus-ci.com/task/5963254039052288> (It would be nice if we > >>>> could see config.log on failure.) > >>> Since dash won't help us to get the build time down sufficiently, and > the > >>> tests don't pass without a separate build tree, I looked at what makes > >>> config/prep_buildtree so slow. > >>> > >>> It's largely just bad code. The slowest part are spawning one expr and > mkdir > >>> -p for each directory. One 'cmp' for each makefile doesn't help either. > >>> > >>> The expr can be replaced with > >>> subdir=${item#$sourcetree} > >>> that's afaics posix syntax ([1]), not bash. > >>> > >>> Spawning one mkdir for each directory can be replaced by a single mkdir > >>> invocation with all the directories. On my linux workstation that gets > the > >>> time for the first loop down from 1005ms to 38ms, really. > >> Even better? > >> > >> (cd "$sourcetree" && find . -print |grep -E '/Makefile$|/GNUmakefile$' > |grep -v "$sourcetree/doc/src/sgml/images/" |xargs tar c) | > >> (cd "$buildtree" && tar x) > > Don't think we depend on tar for building, at the moment. But yes, it'd > be > > faster... Tar is certainly a smaller dependency than perl, not sure if > there's > > any relevant platform without it? > > > > > > > Couple of things here. > > > 1. The second grep should lose "$sourcetree" I think. > > 2. Isn't this going to be a change in behaviour in that it will copy > rather than symlinking the Makefiles? That is in fact the default > behaviour of msys2's 'ln -s', as I pointed out upthread, but I don't > think it's what we really want, especially in the general case. If you > modify the Makefile and you're using a vpath you want to see the change > reflected in your vpath. > > > cheers > > > andrew > > -- > Andrew Dunstan > EDB: https://www.enterprisedb.com > >
v3-0001-Added-Windows-with-MinGW-environment-in-Cirrus-CI.patch
Description: Binary data