Linux x64 clobber build, tip of m-c (0a17cde2a4b6) is failing for me during configure: make: Entering directory `/home/jlebar/code/moz/ff-git/debug/config' ../config/autoconf.mk:668: ../src/config/baseconfig.mk: No such file or directory Makefile:53: ../src/config/config.mk: No such file or directory Makefile:58: ../src/config/rules.mk: No such file or directory make: *** No rule to make target `../src/config/rules.mk'. Stop.
How is your mozconfig?
Created attachment 649034 [details] [diff] [review] Make top_srcdir absolute in config.status This should work as a workaround, provided that pwd returns a msys path on windows. I however would like to fix this more nicely.
Don't rely on pwd to return an msys path on Windows. See bug 777798.
(In reply to Mike Hommey [:glandium] from comment #2) > How is your mozconfig? . $topsrcdir/browser/config/mozconfig mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../debug ac_add_options --srcdir=../src ac_add_options --enable-trace-malloc ac_add_options --enable-debug ac_add_options --disable-optimize ac_add_options --with-ccache mk_add_options MOZ_MAKE_FLAGS="-j16" ac_add_options --enable-application=browser
Oh, I see how that srcdir is getting in there now. Maybe I don't need srcdir anymore; it was to make ccache happier caching object files between checkouts, but perhaps our build or ccache has become smarter since then.
As expected, removing the explicit srcdir fixes the problem for me. I'm still not sure if it's doing anything good for me.
FWIW, this happens if you either build with a relative --srcdir like you did, or just run configure directly, from a relative directory.
Considering this doesn't affect building with make -f client.mk under "normal" circumstances, I'll leave bug 774032 in. Actual fix coming next.
Created attachment 649078 [details] [diff] [review] Fix ConfigStatus.py for the case where top_srcdir is a path relative to topobjdir. It turns out the unittest was completely wrong for testing srcdir, so this bug came through while it shouldn't have :-/
I hope that this may fix the l10n repacks, too, need to see in the next nightlies.
I pushed a followup to unbreak pymake (and hopefully not rebreak anything else). https://hg.mozilla.org/mozilla-central/rev/c8d94fe7506a