Fix --disable-compile-environment a little

RESOLVED FIXED in Firefox 28

Status

()

Firefox
Build Config
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: Pike, Assigned: glandium)

Tracking

unspecified
Firefox 28
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa-], URL)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
There are apparently a few things that broke with --disable-compile-environment.

We're mostly still having that to allow localizers to create local test builds and language packs without installing compiler toolchains.

https://developer.mozilla.org/en-US/docs/Creating_a_Language_Pack has docs, which are probably partly wrong.

But there are also some build config issues, the least of which is that /moz.build doesn't pick up the app build dirs if --disable-compile-environment is specified. That probably tries to mimmick what http://hg.mozilla.org/mozilla-central/rev/05734cb6e140 from bug 498330 did to fix distclean.
(Reporter)

Comment 1

5 years ago
Created attachment 745829 [details] [diff] [review]
use the app for disable-compile-environment in both moz.build and Makefile

Mike, I reverted the Makefile.in part from bug 498330. It didn't really fix distclean for --disable-compile-environment to begin with. Yes, the target didn't fail, but it didn't distclean either, so wth.

distclean seems to be broken in general right now, too.

Passed building on three platforms on try, https://tbpl.mozilla.org/?tree=Try&rev=e10e2569f489
Assignee: nobody → l10n
Status: NEW → ASSIGNED
Attachment #745829 - Flags: review?(mh+mozilla)
(Assignee)

Comment 2

5 years ago
Comment on attachment 745829 [details] [diff] [review]
use the app for disable-compile-environment in both moz.build and Makefile

Review of attachment 745829 [details] [diff] [review]:
-----------------------------------------------------------------

::: Makefile.in
@@ -25,2 @@
>  include $(topsrcdir)/$(MOZ_BUILD_APP)/build.mk
> -endif

You might as well just revert bug 498330 completely, instead of just removing 2 thirds of it. The configure.in part is useless once you revert this.
Attachment #745829 - Flags: review?(mh+mozilla) → review+
(Assignee)

Comment 3

4 years ago
I'm revisiting this bug.
Assignee: l10n → mh+mozilla
Depends on: 934338, 934337, 934336, 934332
Summary: Can't do l10n build targets for installer repacks and language packs with --disable-compile-environment → Fix --disable-compile-environment a little
(Assignee)

Updated

4 years ago
Depends on: 934344
(Assignee)

Comment 4

4 years ago
Created attachment 826604 [details] [diff] [review]
Fix --disable-compile-environment a little

Kind of hackishly awful and not exhaustive, but I think it gets us in a kind of better situation.
Attachment #826604 - Flags: review?(gps)

Comment 5

4 years ago
Comment on attachment 826604 [details] [diff] [review]
Fix --disable-compile-environment a little

Review of attachment 826604 [details] [diff] [review]:
-----------------------------------------------------------------

Oy. I wouldn't be surprised if we missed some ifdef COMPILE_ENVIRONMENT. But we can chase that tail later.

::: Makefile.in
@@ +22,5 @@
>  include $(topsrcdir)/config/config.mk
>  
> +ifndef LIBXUL_SDK
> +ifdef COMPILE_ENVIRONMENT
> +BUILD_JS = 1

\o/

::: config/rules.mk
@@ +664,5 @@
>  OBJ_TARGETS = $(OBJS) $(PROGOBJS) $(HOST_OBJS) $(HOST_PROGOBJS)
>  
>  compile:: $(OBJ_TARGETS)
>  
>  include $(topsrcdir)/config/makefiles/target_libs.mk

I guess we'll have to ensure non-compile libs targets don't get ported to target_libs.mk. Care to add a giant comment at the top of that file? Or maybe we'd feel better if we just ifdef COMPILE_ENVIRONMENT inside that file.
Attachment #826604 - Flags: review?(gps) → review+
(Assignee)

Comment 6

4 years ago
(In reply to Gregory Szorc [:gps] from comment #5)
> I guess we'll have to ensure non-compile libs targets don't get ported to
> target_libs.mk. Care to add a giant comment at the top of that file? Or
> maybe we'd feel better if we just ifdef COMPILE_ENVIRONMENT inside that file.

08:15 <glandium> gps: how about renaming target_libs.mk to target_binaries.mk?
08:20 <gps> glandium: WFM!
(Assignee)

Comment 7

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/2eb99b1ad61f
https://hg.mozilla.org/mozilla-central/rev/2eb99b1ad61f
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 28
Configure now fails for me on Ubuntu 12.04 LTS 64bit, with these errors:

 0:17.93 configure:25999: checking for sys/int_types.h
 0:17.93 configure:26012: /usr/bin/ccache gcc -c  -std=gnu99 -fgnu89-inline -fno-strict-aliasing -fno-math-errno -pthread -pipe  conftest.c 1>&5
 0:17.93 configure:26006:27: fatal error: sys/int_types.h: No such file or directory
 0:17.93 compilation terminated.
 0:17.93 configure: failed program was:
 0:17.93 #line 26004 "configure"
 0:17.93 #include "confdefs.h"
 0:17.93 
 0:17.93 #include <sys/int_types.h>
 0:17.93 int main() {
 0:17.93 
 0:17.93 ; return 0; }
 0:17.93 *** Fix above errors and then restart with               "/usr/bin/make -f client.mk build"


Here is my mozconfig:

ac_add_options --enable-application=browser
ac_add_options --with-ccache

ac_add_options --enable-tests
ac_add_options --enable-debug
ac_add_options --disable-optimize
ac_add_options --enable-valgrind
ac_add_options --enable-warnings-as-errors

mk_add_options MOZ_OBJDIR=./obj-firefox-debug
mk_add_options MOZ_MAKE_FLAGS="-j8 -s"
Still happening with current m-c tip, e474c865fa81.
If I create an empty file at /usr/include/sys/int_types.h, I now get:

 0:17.98 /hack/mozilla-central/configure: 29563: /hack/mozilla-central/configure: Syntax error: end of file unexpected (expecting "fi")

(this is the end of the configure file)
Hm, backing out 2eb99b1ad61f doesn't fix the problem, filing a separate bug.

Updated

4 years ago
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.