Added target specific var generation magic may help simplify/document some common use cases and support automated cleanup. ::: browser/app/Makefile.in @@ +199,5 @@ > > +libs-preqs = \ > + $(call mkdir_deps,$(dist_dest)/Contents/MacOS) \ > + $(call mkdir_deps,$(dist_dest)/Contents/Resources/$(AB).lproj) \ > + $(NULL) I'm starting to wonder if it'd be worthwhile to add magic vars like "GENERATED_libs_DIRS / GENERATED_export_DIRS" etc. Food for thought. +++ This bug was initially created as a clone of Bug #739710 +++ Makefile.in beneath: browser/ ipc/ mobile/ tools/ testing/

Comment on attachment 713485 [details] [diff] [review] mkdir_deps - target specific enhancement Added GENERATED_DIRS_${target} = logic to simplify specifying target specific directory pre-reqs. Removed tmpauto and GENERATED_DIRS_DEPS macros since they will not have a use outside autotargets.mk. Assign the list of directory deps directly to AUTO_DEPS.

Comment on attachment 713485 [details] [diff] [review] mkdir_deps - target specific enhancement >-## Accumulate deps and cleanup >-ifneq (,$(GENERATED_DIRS)) >+########################################################################### >+## GENERATED_DIR(_\S+)? directory deps >+## GENERATED_DIRS_{export,lib,tools} = foo >+########################################################################### >+ifneq (,$(filter GENERATED_DIRS%,$(.VARIABLES))) Filtering on $(.VARIABLES) seems a bit ugly. Even if the variables are all undefined, I think something like this should still work: GENERATED_DIRS += $(foreach tgt,$(MAKECMDGOALS),$(value GENERATED_DIRS_$(tgt))) GENERATED_DIRS := $(strip $(sort $(GENERATED_DIRS))) ifneq (,$(GENERATED_DIRS)) GARBAGE_DIRS += $(GENERATED_DIRS) AUTO_DEPS += $(call mkdir_deps,GENERATED_DIRS) endif >+ # Append target specific deps >+ GENERATED_DIRS += $(foreach tgt,$(MAKECMDGOALS),$(value GENERATED_DIRS_$(tgt))) >+ > GENERATED_DIRS := $(strip $(sort $(GENERATED_DIRS))) >- tmpauto :=$(call mkdir_deps,GENERATED_DIRS) >- GENERATED_DIRS_DEPS +=$(tmpauto) >- GARBAGE_DIRS +=$(GENERATED_DIRS) >+ GARBAGE_DIRS += $(GENERATED_DIRS) >+ >+ AUTO_DEPS += $(call mkdir_deps,GENERATED_DIRS) > endif Also it looks like GENERATED_DIRS_DEPS is going away. There is a reference to that in config/makefiles/test/check-autotargets.mk - I'm not sure what that is used for but the reference to it should probably go away there as well.

(In reply to Michael Shal [:mshal] from comment #3) > Comment on attachment 713485 [details] [diff] [review] > mkdir_deps - target specific enhancement > > >+ifneq (,$(filter GENERATED_DIRS%,$(.VARIABLES))) > > Filtering on $(.VARIABLES) seems a bit ugly. Even if the variables are all > undefined, I think something like this should still work: The conditional was added so logic would only impose processing overhead when needed { makefiles that define GENERATED* }. If the logic were wrapped in a function call that hid $(.VARABLES) -- ifDefined('GENERATED_DIRS%') would that make it more palatable ? > GENERATED_DIRS += $(foreach tgt,$(MAKECMDGOALS),$(value > GENERATED_DIRS_$(tgt))) > GENERATED_DIRS := $(strip $(sort $(GENERATED_DIRS))) > >+ AUTO_DEPS += $(call mkdir_deps,GENERATED_DIRS) > > endif > > Also it looks like GENERATED_DIRS_DEPS is going away. Do you know what bug deprecation is part of or timeframe that will happen in ? > There is a reference to that in config/makefiles/test/check-autotargets.mk - I'm not sure what that is used for but the reference to it should probably go away there as well. This is a unit test that has fallen into disrepair. makefiles have been modified but the unit tests were not maintained alongside the edits.

(In reply to Joey Armstrong [:joey] from comment #4) > (In reply to Michael Shal [:mshal] from comment #3) > > Comment on attachment 713485 [details] [diff] [review] > > mkdir_deps - target specific enhancement > > > > >+ifneq (,$(filter GENERATED_DIRS%,$(.VARIABLES))) > > > > Filtering on $(.VARIABLES) seems a bit ugly. Even if the variables are all > > undefined, I think something like this should still work: > > The conditional was added so logic would only impose processing overhead > when needed { makefiles that define GENERATED* }. If the logic were wrapped > in a function call that hid $(.VARABLES) -- ifDefined('GENERATED_DIRS%') > would that make it more palatable ? I would think iterating over $(.VARIABLES) would involve the most overhead, but I admit I have not benchmarked it. I don't think wrapping it in a function would be better - it just seemed like a strange use of $(.VARIABLES), and it isn't used anywhere else in the Makefiles. > > > GENERATED_DIRS += $(foreach tgt,$(MAKECMDGOALS),$(value > > GENERATED_DIRS_$(tgt))) > > GENERATED_DIRS := $(strip $(sort $(GENERATED_DIRS))) > > > > >+ AUTO_DEPS += $(call mkdir_deps,GENERATED_DIRS) > > > endif > > > > Also it looks like GENERATED_DIRS_DEPS is going away. > > Do you know what bug deprecation is part of or timeframe that will happen in > ? Sorry, I worded that strangely. It looks like you removed the variable definition of GENERATED_DIRS_DEPS as part of this patch: - GENERATED_DIRS_DEPS +=$(tmpauto) Grepping through the tree, the only place that I saw GENERATED_DIRS_DEPS anymore was in that check-autotargets.mk file. So, I thought GENERATED_DIRS_DEPS was going away because it looks like you're removing it. Should it be removed from check-autotargets.mk as well?

(In reply to Michael Shal [:mshal] from comment #5) > I would think iterating over $(.VARIABLES) would involve the most overhead, > but I admit I have not benchmarked it. I don't think wrapping it in a > function would be better - it just seemed like a strange use of > $(.VARIABLES), and it isn't used anywhere else in the Makefiles. Ok fair enough, I'll probably profile this just to see where time is being spent. I suppose this could be considered a micro-optimization anyway considering string manipulation is involved. > > > >+ AUTO_DEPS += $(call mkdir_deps,GENERATED_DIRS) > > > > endif > > > > > > Also it looks like GENERATED_DIRS_DEPS is going away. > > > > Do you know what bug deprecation is part of or timeframe that will happen in > > ? > > Sorry, I worded that strangely. It looks like you removed the variable > definition of GENERATED_DIRS_DEPS as part of this patch: > > - GENERATED_DIRS_DEPS +=$(tmpauto) Heh ok that is good to hear :). There was a comment in notes about removal of this macro so this seemed like wider scope. > Grepping through the tree, the only place that I saw GENERATED_DIRS_DEPS > anymore was in that check-autotargets.mk file. So, I thought > GENERATED_DIRS_DEPS was going away because it looks like you're removing it. > Should it be removed from check-autotargets.mk as well? Yes probably should spend some time cleaning up the test to get it back in working order. Thanks

Comment on attachment 715724 [details] [diff] [review] mkdir_deps - target specific enhancement Fixed mshal's nit's - ignore conditional evaluation based on .VARIABLES and replaced GENERATED_DEPS_DIRS references from the unit test with GENERATED_DIRS_tools. ping on code review: Added GENERATED_DIRS_${target} = logic to simplify specifying target specific directory pre-reqs. Removed tmpauto and GENERATED_DIRS_DEPS macros since they will not have a use outside autotargets.mk. Assign the list of directory deps directly to AUTO_DEPS.

Comment on attachment 716179 [details] [diff] [review] mkdir_deps - target specific enhancement Let's try this again: Fixed mshal's nit's - ignore conditional evaluation based on .VARIABLES and replaced GENERATED_DEPS_DIRS references from the unit test with GENERATED_DIRS_tools. Added GENERATED_DIRS_${target} = logic to simplify specifying target specific directory pre-reqs. Removed tmpauto and GENERATED_DIRS_DEPS macros since they will not have a use outside autotargets.mk. Assign the list of directory deps directly to AUTO_DEPS. Added helper function expand() for library function use to expand macro values. This will correct a problem caused by unexpanded/literal '$(var)' strings being passed to mkdir_deps when GEN*DIR* is assigned to using '=' rather than ':='.

ping on the code review

Comment on attachment 716179 [details] [diff] [review] mkdir_deps - target specific enhancement Review of attachment 716179 [details] [diff] [review]: ----------------------------------------------------------------- This looks good to me. Although with moz.build files, we will need to move the GENERATED_DIRS variables over eventually. Long term, I'm not sure of the overall value of all this mkdir logic. IMO, we could just have moz.build backend prepopulate all the required directories at backend generation time. That way we don't need to burden the build backend with directory exists dependency checks and litter the tree with .mkdir.done files. ::: config/makefiles/autotargets.mk @@ +48,5 @@ > # Extract directory path from a dependency file. > mkdir_stem =$(foreach val,$(getargv),$(subst /.mkdir.done,$(NULL),$(val))) > > +# := expansion for function use > +expand = $(eval func-expand-$(1) := $($(1)))$(func-expand-$(1)) Could you move the trailing $(func-expand-$(1)) to a line continuation or at least document what's going on? It's not completely obvious that this is essentially: eval(func-expand-$1 := $1()) func-expand-$1()

(In reply to Gregory Szorc [:gps] from comment #13) > Comment on attachment 716179 [details] [diff] [review] > mkdir_deps - target specific enhancement > > Review of attachment 716179 [details] [diff] [review]: > ----------------------------------------------------------------- > > This looks good to me. > > Although with moz.build files, we will need to move the GENERATED_DIRS > variables over eventually. > > Long term, I'm not sure of the overall value of all this mkdir logic. IMO, > we could just have moz.build backend prepopulate all the required > directories at backend generation time. That way we don't need to burden the > build backend with directory exists dependency checks and litter the tree > with .mkdir.done files. Well with the enhancements added in we gain benefit now from not having to spawn extra shells/mkdir calls needlessly and the makefile syntax has been cleaned up and simplified. The logic will be ported to moz.build syntax at some point but IMHO cleaning up syntax and gaining benefit now -VS- waiting an indeterminant amount of time for it to be supported on the backend does not make a lot of sense. This is why dependency problems have persisted for-ev-er as there is always a future answer on the horizion. Fix issues now, gain benefit and the transition over to mozbuild should be lateral/a nop later. If in fact directory creation is not needed simply remove or rename the one line makefile assignment where they were defined. Any stray .mkdir.done files will disappear with the next clobber build. > ::: config/makefiles/autotargets.mk > @@ +48,5 @@ > > # Extract directory path from a dependency file. > > mkdir_stem =$(foreach val,$(getargv),$(subst /.mkdir.done,$(NULL),$(val))) > > > > +# := expansion for function use > > +expand = $(eval func-expand-$(1) := $($(1)))$(func-expand-$(1)) > > Could you move the trailing $(func-expand-$(1)) to a line continuation or at > least document what's going on? It's not completely obvious that this is > essentially: > > eval(func-expand-$1 := $1()) > func-expand-$1() Hmmm since this pathch has been tested how about landing it as-is and I can add line continuation change in a followup bug { maybe use $(strip) to span lines + indent ? Inserting a line break could run the risk of inserting embedded whitespace into nested expansions.

(In reply to Joey Armstrong [:joey] from comment #14) > > ::: config/makefiles/autotargets.mk > > @@ +48,5 @@ > > > # Extract directory path from a dependency file. > > > mkdir_stem =$(foreach val,$(getargv),$(subst /.mkdir.done,$(NULL),$(val))) > > > > > > +# := expansion for function use > > > +expand = $(eval func-expand-$(1) := $($(1)))$(func-expand-$(1)) > > > > Could you move the trailing $(func-expand-$(1)) to a line continuation or at > > least document what's going on? It's not completely obvious that this is > > essentially: > > > > eval(func-expand-$1 := $1()) > > func-expand-$1() > > Hmmm since this pathch has been tested how about landing it as-is and I can > add line continuation change in a followup bug { maybe use $(strip) to span > lines + indent ? Inserting a line break could run the risk of inserting > embedded whitespace into nested expansions. Could we at least get a comment?

(In reply to Gregory Szorc [:gps] from comment #15) > (In reply to Joey Armstrong [:joey] from comment #14) > > > ::: config/makefiles/autotargets.mk > > > @@ +48,5 @@ > > > > # Extract directory path from a dependency file. > > > > mkdir_stem =$(foreach val,$(getargv),$(subst /.mkdir.done,$(NULL),$(val))) > > > > > > > > +# := expansion for function use > > > > +expand = $(eval func-expand-$(1) := $($(1)))$(func-expand-$(1)) > > > > > > Could you move the trailing $(func-expand-$(1)) to a line continuation or at > > > least document what's going on? It's not completely obvious that this is > > > essentially: > > > > > > eval(func-expand-$1 := $1()) > > > func-expand-$1() > > > > Hmmm since this pathch has been tested how about landing it as-is and I can > > add line continuation change in a followup bug { maybe use $(strip) to span > > lines + indent ? Inserting a line break could run the risk of inserting > > embedded whitespace into nested expansions. > > Could we at least get a comment? Yes I can add more verbage to the existing comment.

Inbound push: https://hg.mozilla.org/integration/mozilla-inbound/rev/7f12ca5e6d0a

(In reply to Joey Armstrong [:joey] from comment #17) > Inbound push: > https://hg.mozilla.org/integration/mozilla-inbound/rev/7f12ca5e6d0a committed changeset 123725:7f12ca5e6d0a

Could this have caused bug 848452, l10n repacks on linux32 being busted with DEBUG: doshell environment: {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'TZ': 'EST5EDT', 'HOSTNAME': 'mock', 'HOME': '/builds', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TMPDIR': '/tmp'} DEBUG: doshell: command: /usr/bin/env make DEBUG: child environment: {'LANG': 'en_US.UTF-8', 'TERM': 'vt100', 'SHELL': '/bin/bash', 'TZ': 'EST5EDT', 'HOSTNAME': 'mock', 'HOME': '/builds', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'TMPDIR': '/tmp'} mkdir -p ".deps/" /tools/gcc-4.5-0moz3/bin/gcc -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -I../config -I. -I../dist/include -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nspr -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nss -fPIC -Wall -Wpointer-arith -Wdeclaration-after-statement -Werror=return-type -Wtype-limits -Wempty-body -Wno-unused -Wcast-align -std=gnu99 -fgnu89-inline -fno-strict-aliasing -ffunction-sections -fdata-sections -pthread -pipe -DNDEBUG -DTRIMMED -g -O3 -fomit-frame-pointer -include ../mozilla-config.h -DMOZILLA_CLIENT -MD -MF .deps/elf-dynstr-gc.pp -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -o elf-dynstr-gc elf-dynstr-gc.c -lpthread -Wl,-z,noexecstack -Wl,--build-id -Wl,-rpath-link,/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/bin -Wl,-rpath-link,/usr/local/lib -lgobject-2.0 -lglib-2.0 nsinstall.c /tools/gcc-4.5-0moz3/bin/gcc -o host_nsinstall.o -c -DXP_UNIX -O3 -DUNICODE -D_UNICODE -I../config -I. -I../dist/include -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nspr -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nss -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nspr /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/config/nsinstall.c pathsub.c /tools/gcc-4.5-0moz3/bin/gcc -o host_pathsub.o -c -DXP_UNIX -O3 -DUNICODE -D_UNICODE -I../config -I. -I../dist/include -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nspr -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nss -I/builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/dist/include/nspr /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/config/pathsub.c /tools/gcc-4.5-0moz3/bin/gcc -o nsinstall_real -DXP_UNIX -O3 -DUNICODE -D_UNICODE host_nsinstall.o host_pathsub.o cp nsinstall_real nsinstall.tmp mv nsinstall.tmp nsinstall /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/_virtualenv/bin/python /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/config/../config/nsinstall.py -m 644 "nsinstall" "../dist/bin" /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/_virtualenv/bin/python /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/config/../config/nsinstall.py -m 644 "../mozilla-config.h" "../dist/include" /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/_virtualenv/bin/python /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/config/../config/nsinstall.py -m 644 "../config/nsStaticComponents.h" "../dist/include" rm -f ../config/final-link-comps ../config/final-link-libs ../config/final-link-comp-names /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/_virtualenv/bin/python ../toolkit/xre/make-platformini.py --print-buildid > buildid /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/_virtualenv/bin/python ../config/Preprocessor.py -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT -DJSGC_INCREMENTAL=1 -DMOZ_ENABLE_PROFILER_SPS=1 -DMOZILLA_VERSION=\"22.0a1\" -DMOZILLA_VERSION_U=22.0a1 -DMOZILLA_UAVERSION=\"22.0\" -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_SSIZE_T=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_SIGINFO_T=1 -DHAVE_UINT=1 -DHAVE_UNAME_DOMAINNAME_FIELD=1 -DHAVE_VISIBILITY_HIDDEN_ATTRIBUTE=1 -DHAVE_VISIBILITY_ATTRIBUTE=1 -DHAVE_DIRENT_H=1 -DHAVE_GETOPT_H=1 -DHAVE_SYS_BITYPES_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_GNU_LIBC_VERSION_H=1 -DHAVE_NL_TYPES_H=1 -DHAVE_MALLOC_H=1 -DHAVE_X11_XKBLIB_H=1 -DHAVE_CPUID_H=1 -DHAVE_SYS_QUOTA_H=1 -DHAVE_SYS_SYSMACROS_H=1 -DHAVE_LINUX_QUOTA_H=1 -DHAVE_LINUX_IF_ADDR_H=1 -DHAVE_LINUX_RTNETLINK_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_BYTESWAP_H=1 -DHAVE_SYS_CDEFS_H=1 -DHAVE_DLOPEN=1 -DHAVE_DLADDR=1 -DHAVE_MEMMEM=1 -DFUNCPROTO=15 -D_REENTRANT=1 -DHAVE_RANDOM=1 -DHAVE_STRERROR=1 -DHAVE_LCHOWN=1 -DHAVE_FCHMOD=1 -DHAVE_SNPRINTF=1 -DHAVE_MEMMOVE=1 -DHAVE_STAT64=1 -DHAVE_LSTAT64=1 -DHAVE_TRUNCATE64=1 -DHAVE_SETBUF=1 -DHAVE_ISATTY=1 -DHAVE_FLOCKFILE=1 -DHAVE_LOCALTIME_R=1 -DHAVE_STRTOK_R=1 -DHAVE_CLOCK_MONOTONIC=1 -DHAVE_RES_NINIT=1 -DHAVE_GNU_GET_LIBC_VERSION=1 -DHAVE_LANGINFO_CODESET=1 -DVA_COPY=va_copy -DHAVE_VA_COPY=1 -DHAVE_THREAD_TLS_KEYWORD=1 -DMALLOC_H=\<malloc.h\> -DHAVE_STRNDUP=1 -DHAVE_POSIX_MEMALIGN=1 -DHAVE_MEMALIGN=1 -DHAVE_VALLOC=1 -DHAVE_MALLOC_USABLE_SIZE=1 -DHAVE_I18N_LC_MESSAGES=1 -DHAVE_LOCALECONV=1 -DNS_ATTR_MALLOC=__attribute__\(\(malloc\)\) -DNS_WARN_UNUSED_RESULT=__attribute__\(\(warn_unused_result\)\) -DMOZ_UPDATE_CHANNEL=nightly -DMOZ_PHOENIX=1 -DMOZ_BUILD_APP=browser -DMOZ_X11=1 -DMOZ_WIDGET_GTK2=1 -DMOZ_WIDGET_GTK=2 -DMOZ_PDF_PRINTING=1 -DMOZ_ENABLE_XREMOTE=1 -DMOZ_INSTRUMENT_EVENT_LOOP=1 -DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DMOZ_PANGO=1 -DMOZ_ENABLE_GIO=1 -DMOZ_ENABLE_GCONF=1 -DMOZ_ENABLE_DBUS=1 -DIBMBIDI=1 -DACCESSIBILITY=1 -DNS_PRINTING=1 -DNS_PRINT_PREVIEW=1 -DMOZ_WEBRTC=1 -DMOZ_WEBRTC_SIGNALING=1 -DMOZ_PEERCONNECTION=1 -DMOZ_SCTP=1 -DMOZ_SRTP=1 -DMOZ_SAMPLE_TYPE_FLOAT32=1 -DMOZ_RAW=1 -DMOZ_OGG=1 -DATTRIBUTE_ALIGNED_MAX=64 -DMOZ_WEBM=1 -DMOZ_DASH=1 -DMOZ_MEDIA_NAVIGATOR=1 -DMOZ_VP8=1 -DMOZ_VP8_ERROR_CONCEALMENT=1 -DMOZ_VP8_ENCODER=1 -DVPX_X86_ASM=1 -DMOZ_WAVE=1 -DMOZ_SYDNEYAUDIO=1 -DMOZ_SPEEX_RESAMPLER=1 -DMOZ_SOUNDTOUCH=1 -DMOZ_CUBEB=1 -DMOZ_MEDIA=1 -DMOZ_VORBIS=1 -DMOZ_OPUS=1 -DMOZ_WEBVTT=1 -DMOZ_CUBEB=1 -DENABLE_SYSTEM_EXTENSION_DIRS=1 -DMOZ_CRASHREPORTER=1 -DMOZ_CRASHREPORTER_ENABLE_PERCENT=100 -DLIBJPEG_TURBO_X86_ASM=1 -DMOZ_FLEXBOX=1 -DMOZ_WEBAPP_RUNTIME=1 -DMOZ_SIGNING=1 -DMOZ_UPDATER=1 -DMOZ_FEEDS=1 -DMOZ_SAFE_BROWSING=1 -DMOZ_URL_CLASSIFIER=1 -DGL_PROVIDER_GLX=1 -DMOZ_DEBUG_SYMBOLS=1 -DMOZ_LOGGING=1 -DSIZEOF_INT_P=4 -DMOZ_MEMORY_SIZEOF_PTR_2POW=2 -DMOZ_MEMORY=1 -DMOZ_MEMORY_LINUX=1 -DJSGC_INCREMENTAL=1 -DHAVE___CXA_DEMANGLE=1 -DHAVE__UNWIND_BACKTRACE=1 -DJS_DEFAULT_JITREPORT_GRANULARITY=3 -DMOZ_OMNIJAR=1 -DMOZ_USER_DIR=\".mozilla\" -DMOZ_STATIC_JS=1 -DHAVE_FT_BITMAP_SIZE_Y_PPEM=1 -DHAVE_FT_GLYPHSLOT_EMBOLDEN=1 -DHAVE_FT_LOAD_SFNT_TABLE=1 -DHAVE_FT_SELECT_SIZE=1 -DHAVE_FONTCONFIG_FCFREETYPE_H=1 -DMOZ_TREE_PIXMAN=1 -DHAVE_STDINT_H=1 -DHAVE_INTTYPES_H=1 -DMOZ_TREE_CAIRO=1 -DHAVE_UINT64_T=1 -DMOZ_ENABLE_SKIA=1 -DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DBUILD_CTYPES=1 -DMOZ_PLACES=1 -DMOZ_SERVICES_COMMON=1 -DMOZ_SERVICES_CRYPTO=1 -DMOZ_SERVICES_HEALTHREPORT=1 -DMOZ_SERVICES_METRICS=1 -DMOZ_SERVICES_SYNC=1 -DMOZ_MACBUNDLE_ID=org.mozilla.nightly -DMOZ_B2G_VERSION=\"1.0.0\" -DMOZ_B2G_OS_NAME=\"\" -DMOZ_APP_UA_NAME=\"\" -DMOZ_APP_UA_VERSION=\"22.0a1\" -DFIREFOX_VERSION=22.0a1 -DMOZ_UA_BUILDID=\"\" -DMOZ_TELEMETRY_DISPLAY_REV=2 -DMOZ_DATA_REPORTING=1 -DMOZ_DLL_SUFFIX=\".so\" -DHAVE_POSIX_FALLOCATE=1 -DXP_UNIX=1 -DMOZ_ACCESSIBILITY_ATK=1 -DATK_MAJOR_VERSION=1 -DATK_MINOR_VERSION=28 -DATK_REV_VERSION=0 \ -DMOZ_TREE_CAIRO=1 \ -DMOZ_TREE_PIXMAN=1 \ -DMOZ_NATIVE_HUNSPELL= \ -DMOZ_NATIVE_BZ2= \ -DMOZ_NATIVE_ZLIB= \ -DMOZ_NATIVE_PNG= \ -DMOZ_NATIVE_JPEG= \ -DMOZ_NATIVE_LIBEVENT= \ -DMOZ_NATIVE_LIBVPX= \ ../config/system-headers | /usr/bin/perl ../nsprpub/config/make-system-wrappers.pl system_wrappers /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/config/nsinstall -R system_wrappers ../dist /builds/slave/m-cen-lx-l10n-ntly-00000000000/build/mozilla-central/config/nsinstall: cannot access system_wrappers: No such file or directory make: *** [export] Error 1

(In reply to Axel Hecht [:Pike] from comment #20) > Could this have caused bug 848452, l10n repacks on linux32 being busted with Seems likely, backed out in https://hg.mozilla.org/mozilla-central/rev/eccf45749400

Latest nightlies repack eccf45749400, and linux is there again in both 32 and 64 bits.

closing as an old, makefile specific patch.