mozilla :: #build

17 Apr 2017
16:34tedstarting to get some data:
17:07gpsted: something i just connected the dots on - the hit rate will help us determine the effectiveness of ccache and sccache for local development
17:07gpsbefore, i've been skeptical of caching effectiness for some workflows
17:08gpswe should now get useful data for e.g. change a widely used header and see how much of world is rebuilt
17:09tedwe definitely need to get mach telemetry hooked up this quarter
17:10tedbecause i've seen people gripe about multiple different workflows
17:10tedlike "i pull once a day and someone touched CLOBBER every time and i have to rebuild everything"
17:10tedand "i iterate on a file that gets linked into libxul and have to relink it every time"
17:11gpswe don't even know things like what percentage of people who don't need to build libxul are using artifact builds
17:26tjrHrm. Trying to get rust building with mingw... make[5]: *** No rule to make target '../../toolkit/library/rust/../i686-pc-windows-gnu/release/libgkrust.a', needed by 'xul.dll'. Stop.
17:27tjrI swapped i686-pc-windows-msvc for i686-pc-windows-gnu in build/moz.configure/rust.configure to get that far but then got stymied
17:32tedis what's supposed to build that
17:32tedis RUST_LIBRARY_FILE not being set, or not set correctly?
17:33tedactually sounds like it failed to get built at all and now it's failing trying to link libxul because it's not there
17:33ted$ grep RUST_LIBRARY_FILE /build/debug-mozilla-central/toolkit/library/rust/
17:33tedRUST_LIBRARY_FILE := ../x86_64-unknown-linux-gnu/debug/libgkrust.a
17:33tedon my linux build
17:41tjrRUST_LIBRARY_FILE := ../i686-pc-windows-gnu/release/libgkrust.a
17:42tjrfind . -name libgkrust.a finds nothing, so yes I believe it failed to build at all
17:43tedwhat happens if you run make -C $objdir/toolkit/library/rust/
17:59tedOK so it's running cargo and looks like it's building successfully
17:59teddoes /home/tom/Documents/moz/mingw-work/just-build/obj-mingw/toolkit/library/i686-pc-windows-gnu/release/ have anything in it?
18:00tedobviously the build expects there to be a libgkrust.a
18:02tjrted: It's got stuff, for sure.
18:03tedOK, you just have naming confusion somewhere in the build system
18:03teddoes mingw normally generate .lib files and not .a files?
18:04tedi thought it used .a
18:04tjrNo, it normally makes .a
18:04tedmaybe this is just rustc being squirrelly
18:06tedi guess that's expected
18:06tedjust weird
18:10tedyou'll need to put a special-case in there, i guess
18:10tedfroydnj: ^^]
18:12froydnjI'm not sure whether this is us contravening platform conventions or rustc
18:12froydnjI thought the LIB_SUFFIX on windows was .lib
18:12tedfroydnj: it's rustc and mingw not agreeing
18:12tedis what
18:13froydnjted: great
18:13froydnjI guess we can file a rustc PR?
18:13tednot sure if there's a way to coerce rustc to use .a
18:13* froydnj goes to look
18:13tedotherwise this is probably going to be messy
18:15froydnjok, so this would be a one-line change to rustc
18:19froydnjugh, they were going to keep the .a suffix and got bikeshedded into using .lib for mingw
18:24froydnjok, so I guess we need to add a mingw-specific hack somewhere?
18:24tjrSomewhere, yes. I think ted was proposing in python/mozbuild/mozbuild/frontend/
18:25tedi'm a little worried that that's going to break things elsewhere though
18:25froydnjthat or define a RUST_LIB_SUFFIX somewhere and use that there
18:25tedwith the rest of the build system assuming .a
18:28froydnjthat is a possibility
18:28froydnjbut the rust stuff is fairly well walled off from anything assuming .a
18:29froydnjand mostly interacts via makefile variables, which can set appropriately
18:29tedoh yeah, i suppose so
18:29froydnjI guess if we supported some kind of introspection on the libraries (??), things could definitely break
18:29tedi was thinking the EXPANDLIBS stuff, but that shouldn't be a problem
18:29tedsince these will always be real static libs
18 Apr 2017
No messages
Last message: 158 days and 4 hours ago