mkdir_deps - target specific enhancement.

RESOLVED WONTFIX

Status

()

Core
Build Config
RESOLVED WONTFIX
6 years ago
4 years ago

People

(Reporter: joey, Assigned: joey)

Tracking

unspecified
mozilla22
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

6 years ago
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/
(Assignee)

Updated

6 years ago
No longer blocks: 734139
(Assignee)

Updated

5 years ago
Assignee: nobody → joey
(Assignee)

Comment 1

5 years ago
Created attachment 713485 [details] [diff] [review]
mkdir_deps - target specific enhancement
(Assignee)

Comment 2

5 years ago
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.
Attachment #713485 - Flags: review?(gps)
Attachment #713485 - Flags: feedback?(mshal)
(Assignee)

Updated

5 years ago
Blocks: 734139
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.
Attachment #713485 - Flags: feedback?(mshal) → feedback+
(Assignee)

Comment 4

5 years ago
(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?
(Assignee)

Comment 6

5 years ago
(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
(Assignee)

Comment 7

5 years ago
Created attachment 715724 [details] [diff] [review]
mkdir_deps - target specific enhancement
(Assignee)

Updated

5 years ago
Attachment #713485 - Attachment is obsolete: true
Attachment #713485 - Flags: review?(gps)
(Assignee)

Comment 8

5 years ago
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.
Attachment #715724 - Flags: review?(gps)
(Assignee)

Comment 9

5 years ago
Created attachment 716179 [details] [diff] [review]
mkdir_deps - target specific enhancement
(Assignee)

Updated

5 years ago
Attachment #715724 - Attachment is obsolete: true
Attachment #715724 - Flags: review?(gps)
(Assignee)

Comment 10

5 years ago
https://tbpl.mozilla.org/?tree=Try&rev=28b8fe63a9f2
(Assignee)

Comment 11

5 years ago
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 ':='.
Attachment #716179 - Flags: review?(gps)
(Assignee)

Comment 12

5 years ago
ping on the code review
(Assignee)

Updated

5 years ago
No longer blocks: 734139
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()
Attachment #716179 - Flags: review?(gps) → review+
(Assignee)

Comment 14

5 years ago
(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?
(Assignee)

Comment 16

5 years ago
(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.
(Assignee)

Comment 17

5 years ago
Inbound push: https://hg.mozilla.org/integration/mozilla-inbound/rev/7f12ca5e6d0a
(Assignee)

Comment 18

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

committed changeset 123725:7f12ca5e6d0a
https://hg.mozilla.org/mozilla-central/rev/7f12ca5e6d0a
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22

Comment 20

5 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 22

5 years ago
Latest nightlies repack eccf45749400, and linux is there again in both 32 and 64 bits.
(Assignee)

Comment 23

4 years ago
closing as an old, makefile specific patch.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.