Change build config to allow building with m-c as topsrcdir

RESOLVED FIXED

Status

enhancement
RESOLVED FIXED
2 years ago
Last year

People

(Reporter: Fallen, Assigned: tomprince)

Tracking

Trunk
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(11 attachments, 12 obsolete attachments)

125.12 KB, patch
Details | Diff | Splinter Review
2.08 KB, patch
tomprince
: review-
Pike
: review+
Details | Diff | Splinter Review
59 bytes, text/x-review-board-request
Fallen
: review+
Details
984 bytes, patch
tomprince
: review-
Details | Diff | Splinter Review
7.08 KB, patch
iann_bugzilla
: review+
Details | Diff | Splinter Review
45 bytes, text/x-phabricator-request
Fallen
: review+
Details | Review
45 bytes, text/x-phabricator-request
Fallen
: review+
Details | Review
45 bytes, text/x-phabricator-request
Fallen
: review+
Details | Review
45 bytes, text/x-phabricator-request
Fallen
: review+
Details | Review
45 bytes, text/x-phabricator-request
Fallen
: review+
Details | Review
45 bytes, text/x-phabricator-request
Fallen
: review+
Details | Review
In this bug I'd like to make some build config changes that would allow both what we have currently, but also making m-c the topsrcdir. See meta bug 1366606 for more details.
Posted patch Fix - v1 (obsolete) β€” β€” Splinter Review
This touches various products, to be honest I just ran through the testing for Thunderbird.

The latest try run is here, it matches the failures on c-c at the time:

https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=5d11e5205a6c75dc0c777d190df343de769feeb0
Attachment #8869847 - Flags: review?(frgrahl)
Attachment #8869847 - Flags: review?(florian)
Attachment #8869847 - Flags: review?(Pidgeot18)
Comment on attachment 8869847 [details] [diff] [review]
Fix - v1

Also asking for feedback (or review) from ewong as suggested.
Attachment #8869847 - Flags: feedback?(ewong)
Comment on attachment 8869847 [details] [diff] [review]
Fix - v1

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

::: comm-confvars.sh
@@ +1,3 @@
> +#!/bin/sh
> +
> +if [[ "$MOZ_BUILD_APP" == *comm* ]]

been some time since I last looked at the definition of MOZ_BUILD_APP; but, doesn't it get set to "mail" or "suite" or "im" (for comm-central stuff)?

just wondering.. is this a move to have comm/ build under the mozilla src?
(In reply to Edmund Wong (:ewong) from comment #3)
> Comment on attachment 8869847 [details] [diff] [review]
> Fix - v1
> 
> Review of attachment 8869847 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: comm-confvars.sh
> @@ +1,3 @@
> > +#!/bin/sh
> > +
> > +if [[ "$MOZ_BUILD_APP" == *comm* ]]
> 
> been some time since I last looked at the definition of MOZ_BUILD_APP; but,
> doesn't it get set to "mail" or "suite" or "im" (for comm-central stuff)?
Yes, but if m-c is the topsrcdir and comm a subdir, then it comm/mail, comm/suite and comm/im.

> 
> just wondering.. is this a move to have comm/ build under the mozilla src?
Not sure if this was before or after our IRC discussion. This is a move to allow having comm build under the mozilla src, but still with separate repos. See also the dependent metabug.
Fallen,

I am having trouble applying the patch. Trivial differences but the patch for this one 
calendar\lightning\Makefile.in does not apply at all and contains a few changes. Just a FYI. Will see that I fix it up later.
Posted patch Fix - v1 (obsolete) β€” β€” Splinter Review
I rebased against the latest comm-central, just a minor change in Seamonkey for me. Are you sure you are at the latest tip?
Attachment #8869847 - Attachment is obsolete: true
Attachment #8869847 - Flags: review?(frgrahl)
Attachment #8869847 - Flags: review?(florian)
Attachment #8869847 - Flags: review?(Pidgeot18)
Attachment #8869847 - Flags: feedback?(ewong)
Attachment #8872039 - Flags: review?(frgrahl)
Attachment #8872039 - Flags: review?(florian)
Attachment #8872039 - Flags: review?(Pidgeot18)
Attachment #8872039 - Flags: feedback?(ewong)
Back when I worked on bug 648979, most of these sorts of changes I handled automatically via a script (the script in the bug is out of date, but the basic principles behind it should more or less work). I don't see what sort of script you ran--if any--here, which makes it hard for me to assess if the patch is complete or incomplete.
I didn't script the changes, I grepped for certain markers in Makefile.ins and moz.build files. It is certainly possible that this patch would break us during a beta build or release, I did at least check various targets like mach package.
Comment on attachment 8872039 [details] [diff] [review]
Fix - v1

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

looks about right.
Attachment #8872039 - Flags: feedback?(ewong) → feedback+
Comment on attachment 8872039 [details] [diff] [review]
Fix - v1

Tested building SeaMonkey locally but only with the comm dir as top source dir. As far as I see it everything still works and everything seems to be covered. 

Covering both options adds some additional complexity so as discussed on irc when this is checked in and stable I would like to see building with comm as top source dir removed in a followup bug.

Even if it breaks something in the short term this really should simplify maintaining the configs and build files in the future so r+ from me.

Thanks
Attachment #8872039 - Flags: review?(frgrahl) → review+
Posted patch Fix - v2 β€” β€” Splinter Review
I'd love to move this out of my queue. Development has been so much easier without the hassle of comm issues with the directory switch.

Tom, what is your opinion on this? Does this help for TC at all, or would you solve it in a different way? 

Any chance we can push this nevertheless and deal with the fallout? As mentioned I made all changes manually so there may be unfound issues, but at least for some of the changes I am not sure if they are easily scriptable.
Attachment #8872039 - Attachment is obsolete: true
Attachment #8872039 - Flags: review?(florian)
Attachment #8872039 - Flags: review?(Pidgeot18)
Attachment #8916275 - Flags: review?(mozilla)
Assignee

Updated

2 years ago
Keywords: leave-open
Assignee

Comment 14

2 years ago
Comment on attachment 8916275 [details] [diff] [review]
Fix - v2

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

Looks good, with a couple of minor changes. I'm going to upload an updated patch.

::: mail/build.mk
@@ +8,3 @@
>  
>  package:
> +	$(MAKE) -C $(COMMDEPTH)/mail/installer

This shouldn't lose the @.

@@ +39,3 @@
>  
>  wget-en-US:
>  	$(MAKE) -C mail/locales wget-en-US

This should be updated as well.
Comment hidden (mozreview-request)
Assignee

Comment 16

2 years ago
mozreview-review
Comment on attachment 8917173 [details]
Bug 1366607 - Allow building with m-c as topsrcdir.

https://reviewboard.mozilla.org/r/188188/#review193362
Attachment #8917173 - Flags: review?(mozilla) → review+

Comment 17

2 years ago
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/comm-central/rev/84893db274a4
Allow building with m-c as topsrcdir. r=frg,tomprince
Assignee

Updated

2 years ago
Attachment #8916275 - Flags: review?(mozilla)
Seems that building comm-central/mozilla doesn't work right now?

$ make -d echo-variable-COMMDEPTH|grep app-config
Reading makefile `/src/central/comm-central/../mail/app-config.mk' (search path) (don't care) (no ~ expansion)...
 Considering target file `/src/central/comm-central/../mail/app-config.mk'.
  File `/src/central/comm-central/../mail/app-config.mk' does not exist.
  Looking for an implicit rule for `/src/central/comm-central/../mail/app-config.mk'.
  No implicit rule found for `/src/central/comm-central/../mail/app-config.mk'.
  Finished prerequisites of target file `/src/central/comm-central/../mail/app-config.mk'.
 Must remake target `/src/central/comm-central/../mail/app-config.mk'.
 Failed to remake target file `/src/central/comm-central/../mail/app-config.mk'.

Comment 19

2 years ago
Building seamonkey from source no longer works for me (Linux x86_64). The configure step isn't defining commreltopsrcdir and friends, so app.mozbuild blows up on e.g. include('/%s/mailnews/mailnews.mozbuild' % CONFIG['commreltopsrcdir'])

How is it supposed to work?
I've tried a fresh SeaMonkey build and it goes past the configure step for me. Would be great to figure out what the issue is though.

Regarding COMMDEPTH, Pike, in which case are you getting that?
Ah, I see the COMMDEPTH part is maybe for bug 1396563 and can reproduce with c-c as topsrcdir. Looks like this is from https://dxr.mozilla.org/comm-central/source/mozilla/config/config.mk#414 where MOZ_BUILD_APP is ../mail and topsrcdir is comm-central. I took a brief look and couldn't find anything obvious, Tom maybe you can take a look? Unfortunately I am out of PTO to go in depth.
Flags: needinfo?(mozilla)
Posted patch Fix COMMDEPTH - v1 β€” β€” Splinter Review
Ok, so I did have a little time :) I found an elegant solution that doesn't make use of app-config.mk.
Attachment #8918767 - Flags: review?(mozilla)
Flags: needinfo?(mozilla)
Comment on attachment 8918767 [details] [diff] [review]
Fix COMMDEPTH - v1

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

Tested this locally and looked at where this is hooked up, this looks like a good fix to me.

Up to you to decide on whether my review counts, though :-)
Attachment #8918767 - Flags: review+
Given this will likely fix l10n nightly builds I think we can count it as a bustage fix, the extra set of eyes is very helpful! Push coming up.

Comment 25

2 years ago
Pushed by mozilla@kewis.ch:
https://hg.mozilla.org/comm-central/rev/33577e068081
Change build config to allow building with m-c as topsrcdir - make sure COMMDEPTH is always defined. r=bustage/Pike
Tom, anything else you wanted to take care of before we close this bug?
Flags: needinfo?(mozilla)
Sorry about that, the quick fix didn't seem to do it, this broke something with testsuite-targets:
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=33577e068081b48884ecff324c6d03659e5a561d


I've backed out the changeset so we can go the normal route with try and everything.
https://hg.mozilla.org/comm-central/rev/db6a991ed2ba008bd7f934591250a6079e478d2c
Assignee

Comment 28

2 years ago
It looks like topsrcdir and DEPTH in generated `Makefile`s depend on whether the Makefile.in comes from m-c or c-c (when doing a build with c-c as topdir). That means that https://dxr.mozilla.org/comm-central/source/mozilla/config/config.mk#414 won't find the right file when included from a c-c makefiles in a c-c-topdir build.
Assignee

Comment 29

2 years ago
(In reply to David Edwards from comment #19)
> Building seamonkey from source no longer works for me (Linux x86_64). The
> configure step isn't defining commreltopsrcdir and friends, so app.mozbuild
> blows up on e.g. include('/%s/mailnews/mailnews.mozbuild' %
> CONFIG['commreltopsrcdir'])
> 
> How is it supposed to work?

It is defined by comm-confvars.sh which is included by $(MOZ_BUILD_APP)/confvars.sh (i.e. suite/confvars.sh) which is included from old-configure.in. It is then propagated by the AC_SUBST in $(MOZ_BUILD_APP)/configure.in.
Assignee

Updated

2 years ago
Attachment #8917173 - Attachment is obsolete: true

Comment 31

2 years ago
Thanks for that Tom. My problem is suite/confvars.sh
________________________________________________________
#! /bin/sh
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

source ${_topsrcdir}/$MOZ_BUILD_APP/../comm-confvars.sh
     .
     .
     .
________________________________________________________
'source' is a C-shell rather than a Bourne shell construct, and on my system (Ubuntu 16.04) the script fails with a syntax error.

Replacing 'source' with the Bourne shell '.' fixes it for me.

. ${_topsrcdir}/$MOZ_BUILD_APP/../comm-confvars.sh
Comment hidden (mozreview-request)

Comment 33

2 years ago
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/comm-central/rev/9050482bf464
Refer explicitly to the top comm objdir, rather than using a relative depth; rs=bustage-fix
https://hg.mozilla.org/comm-central/rev/b5a7d14c4cd2
Don't use bashisms in confvars.sh; rs=bustage-fix

Comment 34

2 years ago
confvars.sh now works. But build still fails because nsGNOMEShellService.cpp attempts to include nsIDOMHTMLImageElement.h, which in my case I have not got ...
_____________________________________________________________________________________________________________________________
/home/dme/comm-central/suite/shell/src/nsGNOMEShellService.cpp:25:36: fatal error: nsIDOMHTMLImageElement.h: No such file or directory
_____________________________________________________________________________________________________________________________
David, include the patch for Bug 1406227 for building SeaMonkey. I need to do a lot of check-ins but was busy with l10n fixing yesterday.
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Assignee

Updated

2 years ago
Attachment #8919028 - Attachment is obsolete: true
Assignee

Updated

2 years ago
Attachment #8919114 - Attachment is obsolete: true
Reporter

Comment 41

2 years ago
mozreview-review
Comment on attachment 8919516 [details]
Bug 1366607: Include toolkit moz.configure in m-c topdir build.

https://reviewboard.mozilla.org/r/190338/#review195632

Would be good to do the same change for suite/ and im/ as well, r+ with that
Attachment #8919516 - Flags: review?(philipp) → review+
Reporter

Comment 42

2 years ago
mozreview-review
Comment on attachment 8919517 [details]
Bug 1366607: Use correct include paths for toolkit in xul files.

https://reviewboard.mozilla.org/r/190340/#review195634

::: mail/config/mozconfigs/linux64/nightly
(Diff revision 1)
>  
>  # Package js shell
>  export MOZ_PACKAGE_JSSHELL=1
>  
> -# Run client.py
> -mk_add_options CLIENT_PY_ARGS="$([ -f $topsrcdir/build/client.py-args ] && cat $topsrcdir/build/client.py-args)"

I suspect this was only for testing?
Attachment #8919517 - Flags: review?(philipp) → review+
Reporter

Comment 43

2 years ago
mozreview-review
Comment on attachment 8919518 [details]
Bug 1366607: Use correct include path for `plugin-container.cpp`.

https://reviewboard.mozilla.org/r/190342/#review195636
Attachment #8919518 - Flags: review?(philipp) → review+
Reporter

Comment 44

2 years ago
mozreview-review
Comment on attachment 8919519 [details]
Bug 1366607: Use correct path for cityhash license.

https://reviewboard.mozilla.org/r/190344/#review195638
Attachment #8919519 - Flags: review?(philipp) → review+
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Comment hidden (mozreview-request)
Assignee

Comment 49

2 years ago
mozreview-review-reply
Comment on attachment 8919517 [details]
Bug 1366607: Use correct include paths for toolkit in xul files.

https://reviewboard.mozilla.org/r/190340/#review195634

> I suspect this was only for testing?

Yeah. I guess I missed removing this when I extracted these from my taskcluster branch.

Comment 50

2 years ago
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/comm-central/rev/32a18ec6f4de
Include toolkit moz.configure in m-c topdir build; r=Fallen
https://hg.mozilla.org/comm-central/rev/faa8015c6ae3
Use correct include paths for toolkit in xul files; r=Fallen
https://hg.mozilla.org/comm-central/rev/0a70299b8ece
Use correct include path for `plugin-container.cpp`; r=Fallen
https://hg.mozilla.org/comm-central/rev/c6b8fc410a90
Use correct path for cityhash license; r=Fallen
Comment hidden (mozreview-request)
Assignee

Updated

2 years ago
Attachment #8919516 - Attachment is obsolete: true
Assignee

Updated

2 years ago
Attachment #8919517 - Attachment is obsolete: true
Assignee

Updated

2 years ago
Attachment #8919518 - Attachment is obsolete: true
Assignee

Updated

2 years ago
Attachment #8919519 - Attachment is obsolete: true
Reporter

Comment 52

2 years ago
mozreview-review
Comment on attachment 8919880 [details]
Bug 1366607: Use relative paths in ldap mozbuild includes.

https://reviewboard.mozilla.org/r/190822/#review196042
Attachment #8919880 - Flags: review?(philipp) → review+

Comment 53

2 years ago
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/comm-central/rev/41a5daa174d1
Use relative paths in ldap mozbuild includes; r=Fallen
Did anyone try to build l10n yet with m-c as top? The toml files have mozilla in it which might not work in this case. pike said something about setting mozilla from the command line in bug 1405407 comment 14 but not sure if this needs additional work besides doing it in the makefiles.
Assignee

Comment 55

2 years ago
(In reply to Frank-Rainer Grahl (:frg) from comment #54)
> Did anyone try to build l10n yet with m-c as top? The toml files have
> mozilla in it which might not work in this case. pike said something about
> setting mozilla from the command line in bug 1405407 comment 14 but not sure
> if this needs additional work besides doing it in the makefiles.

I haven't yet. I've been testing this as part of my TaskCluster work, which hasn't got to the point of doing L10N yet. I'll address that when I get to that point.
Flags: needinfo?(mozilla)
Assignee

Comment 56

2 years ago
Comment on attachment 8918767 [details] [diff] [review]
Fix COMMDEPTH - v1

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on c-c, etc.): 
Risk to taking this patch (and alternatives if risky):
Attachment #8918767 - Flags: review?(mozilla) → review-
(In reply to Frank-Rainer Grahl (:frg) from comment #54)
> Did anyone try to build l10n yet with m-c as top? The toml files have
> mozilla in it which might not work in this case. pike said something about
> setting mozilla from the command line in bug 1405407 comment 14 but not sure
> if this needs additional work besides doing it in the makefiles.

You'll need a patch in l10n.mk for this, supporting something as CL_DEFINES, and then set CL_DEFINES to say -Dmozilla=.path.to.mozilla-central
Assignee

Updated

2 years ago
Assignee: philipp → mozilla
I fixed up the SeaMonkey build configs and actually tried it for the first time. 

I am having a problem with EXPAND_LOCALE_SRCDIR in suite/installer/Makefile.in. Should be the same for mail I think because the logic is the same.

In suite PPL_LOCALE_ARGS is set to  

> PPL_LOCALE_ARGS=$(call EXPAND_LOCALE_SRCDIR,suite/locales)/installer/windows

EXPAND_LOCALE_SRCDIR is defined in (mozilla)/config/config.mk as

> EXPAND_LOCALE_SRCDIR = $(if $(filter en-US,$(AB_CD)),$(topsrcdir)/$(1)/en-US,$(or $(realpath $(L10NBASEDIR)),$(abspath $(L10NBASEDIR)))/$(AB_CD)/$(subst /locales,,$(1)))

So with m-c as topsourcedir this will be set to $(topsrcdir)/suite/locales/en-US instead of $(topsrcdir)/comm/suite/locales/en-US

And building ends with an error:

> fp = open(path, "r")
> IOError: [Errno 2] No such file or directory: 'd:/seamonkey/mozilla-central/suite/locales/en-US
> /installer/windows\\override.properties'
> Makefile:57: recipe for target 'uninstaller' failed

If it is the same in TB how to fix it best?
Posted file 1366607-installer.patch (obsolete) β€”
Hmm this seems to work for suite so maybe also for mail?
Attachment #8923860 - Flags: feedback?(mozilla)
Attachment #8923860 - Attachment description: 1366607-installer-patch → 1366607-installer.patch
bungled the extension
Attachment #8923860 - Attachment is obsolete: true
Attachment #8923860 - Flags: feedback?(mozilla)
Assignee

Comment 61

2 years ago
Comment on attachment 8923861 [details] [diff] [review]
1366607-installer.patch

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

::: mail/installer/windows/Makefile.in
@@ +46,5 @@
>  
>  ifdef LOCALE_MERGEDIR
>  PPL_LOCALE_ARGS = \
>    --l10n-dir=$(LOCALE_MERGEDIR)/mail/installer \
> +  --l10n-dir=$(call EXPAND_LOCALE_SRCDIR,$(commreltopsrcdir)/mail/locales)/installer \

This won't work for locales other then en-US. In that case, it wants a path in l10n-central, which doesn't have a comm prefix.
Attachment #8923861 - Flags: review-
Hmm I see. Probably best to fix l10n first and see what is left.

One other. I assume the application in the mozconfig is comm/mail or comm/suite so this probably fails in mail/installer/Makefile.in too:
> DEFINES += -DPKG_LOCALE_MANIFEST=$(topobjdir)/mail/installer/locale-manifest.in

I got over it in suite with

> DEFINES += -DPKG_LOCALE_MANIFEST=$(topobjdir)/$(commreltopsrcdir)/suite/installer/locale-manifest.in

At least en-US builds and works fine then.
Assignee

Comment 63

2 years ago
I think maybe using something like

> EXPAND_COMM_LOCALE_SRCDIR = $(if $(filter en-US,$(AB_CD)),$(topsrcdir)/$(commreltopsrcdir)/$(1)/en-US,$(or $(realpath $(L10NBASEDIR)),$(abspath $(L10NBASEDIR)))/$(AB_CD)/$(subst /locales,,$(1)))

and using that instead of EXPAND_LOCALE_SRCDIR might do the trick (but I just typed that into bugzilla, so totally untested.
Doesn't see to crash and burn but as expected the merge is broken and probably needs to be parametrized as stated in comment 57.

> WARNING:root:WARNING: --locale-mergedir passed, but 'd:/seabuild/release/comm-central-15p/obj-
> x86_64-pc-mingw32/comm/suite/locales/merge-dir/de' does not exist. Ignore this message if the 
> locale is complete.
> INFO:root:processing d:/seamonkey/mozilla-central/comm/suite/locales/jar.mn
Posted patch 1366607-suite-wip.patch (obsolete) β€” β€” Splinter Review
wip patch for suite. Do not open before christmas.
Posted patch 1366607-suite.patch (obsolete) β€” β€” Splinter Review
Prerequisite patch for SeaMonkey in Bug 1405407 is in so better put this one in too before it rots.
Attachment #8923893 - Attachment is obsolete: true
Attachment #8927685 - Flags: review?(iann_bugzilla)
Assignee

Updated

2 years ago
Depends on: 1417319

Comment 67

2 years ago
(In reply to Frank-Rainer Grahl (:frg) from comment #66)
> Created attachment 8927685 [details] [diff] [review]
> 1366607-suite.patch
> 
> Prerequisite patch for SeaMonkey in Bug 1405407 is in so better put this one
> in too before it rots.

Can we port the suite/installer/windows/Makefile.in changes from the above Seamonkey patch for TB to make building on Windows working and land this soon? WFM to build successfully.
Flags: needinfo?(mozilla)
Assignee

Comment 68

2 years ago
MakeMyDay I've got this in my stack of patches, but I'd like to wait for having CI to land it.
Flags: needinfo?(mozilla)
Posted patch 1366607-suite-V2.patch β€” β€” Splinter Review
suite patch updated for recent changes
Attachment #8927685 - Attachment is obsolete: true
Attachment #8927685 - Flags: review?(iann_bugzilla)
Attachment #8931134 - Flags: review?(iann_bugzilla)

Comment 70

2 years ago
Comment on attachment 8931134 [details] [diff] [review]
1366607-suite-V2.patch

>+++ b/suite/configure.in
>-dnl Get other versions (for the calendar plugin)
>-THUNDERBIRD_VERSION=`cat ${_topsrcdir}/../mail/config/version.txt`
>-AC_SUBST(THUNDERBIRD_VERSION)
Isn't this still needed by Lightning or have things changed since this originally went in?

r=me with that answered/addressed.
Attachment #8931134 - Flags: review?(iann_bugzilla) → review+
Comment on attachment 8931134 [details] [diff] [review]
1366607-suite-V2.patch

> Isn't this still needed by Lightning or have things changed since this originally went in?

The version is only calculated from calendar/lightning/versions.mk

This was a leftover from the early days.

Comment 72

2 years ago
Pushed by frgrahl@gmx.net:
https://hg.mozilla.org/comm-central/rev/51ec1985ad3a
Additional changes to allow building SeaMonkey with m-c as topsrcdir. r=IanN
I am seeing a repack error in both TB and SM e.g. here:

https://archive.mozilla.org/pub/thunderbird/nightly/2017/12/2017-12-04-03-02-03-comm-central-l10n/comm-central-linux64-l10n-nightly-af-bm94-build1-build518.txt.gz

This probably comes from \calendar\lightning/Makefile.in

> MOZ_BUILDID = $(shell $(PYTHON) $(MOZILLA_SRCDIR)/config/printconfigsetting.py $(DIST)/bin/application.ini App BuildID)

The build seems to succeed but is it possible the full objectdir needs to be put before $(DIST)/bin?


++ snip ++
Repackaging lightning-6.1a1.af locale for Language af
rm -f -rf ../../dist/xpi-stage/lightning-af
cp -R ../../dist/xpi-stage/lightning ../../dist/xpi-stage/lightning-af
grep -v '^locale [a-z\-]\+ en-US' ../../dist/xpi-stage/lightning-af/chrome.manifest > ../../dist/xpi-stage/lightning-af/chrome.manifest~ && \
  mv ../../dist/xpi-stage/lightning-af/chrome.manifest~ ../../dist/xpi-stage/lightning-af/chrome.manifest
*find /builds/slave/tb-c-cen-l64-l10n-ntly-0000000/build/source/objdir-tb/dist/xpi-stage/lightning-af -name '*en-US*' -print0 | xargs -0 rm -rf**
**Traceback (most recent call last):**
**  File "/builds/slave/tb-c-cen-l64-l10n-ntly-0000000/build/source/mozilla/config/printconfigsetting.py", line 16, in <module>**
**    with open(file) as fh:**
**IOError: [Errno 2] No such file or directory: '../../dist/bin/application.ini'**
*/builds/slave/tb-c-cen-l64-l10n-ntly-0000000/build/source/objdir-tb/_virtualenv/bin/python -m mozbuild.action.preprocessor  -DGRE_MILESTONE=59.0a1
Flags: needinfo?(mozilla)
Assignee

Comment 74

2 years ago
That is an issue unrelated to the m-c change I think (looking at old nightly logs, I can see it as far back as 2017-08-23. 

(In reply to Frank-Rainer Grahl (:frg) from comment #73)

> I am seeing a repack error in both TB and SM e.g. here:
> 
> https://archive.mozilla.org/pub/thunderbird/nightly/2017/12/2017-12-04-03-02-
> 03-comm-central-l10n/comm-central-linux64-l10n-nightly-af-bm94-build1-
> build518.txt.gz
> 
> This probably comes from \calendar\lightning/Makefile.in
> 
> > MOZ_BUILDID = $(shell $(PYTHON) $(MOZILLA_SRCDIR)/config/printconfigsetting.py $(DIST)/bin/application.ini App BuildID)
> 
> The build seems to succeed but is it possible the full objectdir needs to be
> put before $(DIST)/bin?
> [...]
Flags: needinfo?(mozilla)

Updated

2 years ago
Depends on: 1426944
Comment on attachment 8952018 [details]
Bug 1366607: Stop getting SeaMonkey version in Thunderbird's configure; r?Fallen

This might be obsolete now after bug 1309372 moved the version check inside calendar.
Comment on attachment 8952018 [details]
Bug 1366607: Stop getting SeaMonkey version in Thunderbird's configure; r?Fallen

Philipp Kewisch [:Fallen]  has approved the revision.

https://phabricator.services.mozilla.com/D602
Attachment #8952018 - Flags: review+
Attachment #8952018 - Attachment description: Bug 1366607: Get SeaMonkey version from the correct location in an m-c topdir build; r?Fallen → Bug 1366607: Stop getting SeaMonkey version in Thunderbird's configure; r?Fallen
Comment on attachment 8952247 [details]
Bug 1366607: Fix L10N repack of chat and editor with m-c as topdir; r?Fallen

Philipp Kewisch [:Fallen]  has approved the revision.

https://phabricator.services.mozilla.com/D608
Attachment #8952247 - Flags: review+

Comment 80

Last year
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/comm-central/rev/480bf9c55458
Fix L10N repack of chat and editor with m-c as topdir; r=Fallen

Comment 81

Last year
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/comm-central/rev/c99498430e33
Stop getting SeaMonkey version in Thunderbird's configure; r=Fallen
Comment on attachment 8967626 [details]
Bug 1366607: Drop support for building with comm-central in automation mozconfigs; r?Fallen

Philipp Kewisch [:Fallen]  has approved the revision.

https://phabricator.services.mozilla.com/D930
Attachment #8967626 - Flags: review+
Comment on attachment 8967627 [details]
Bug 1366607: Get rid of references to `$commtopsrcdir` in automation mozconfigs; r?Fallen

Philipp Kewisch [:Fallen]  has approved the revision.

https://phabricator.services.mozilla.com/D931
Attachment #8967627 - Flags: review+
Comment on attachment 8967628 [details]
Bug 1366607: Get rid of references to mozconfig.comm-support in thunderbird; r?Fallen

Philipp Kewisch [:Fallen]  has approved the revision.

https://phabricator.services.mozilla.com/D932
Attachment #8967628 - Flags: review+
Comment on attachment 8967630 [details]
Bug 1366607: Remove unused tooltool manifests; r?Fallen

Philipp Kewisch [:Fallen]  has approved the revision.

https://phabricator.services.mozilla.com/D933
Attachment #8967630 - Flags: review+
IIUC after these patches it won't be possible to build with comm-central as topsrcdir? If so, we need to migrate developers over, or at least provide something like client.py that does the checkouts.
Flags: needinfo?(mozilla)
> IIUC after these patches it won't be possible to build with comm-central as topsrcdir?

Seems to be only mail/config which is only used in automation. Local builds should still work fine.

Comment 92

Last year
Pushed by mozilla@hocat.ca:
https://hg.mozilla.org/comm-central/rev/8dc4a26ee33f
Drop support for building with comm-central in automation mozconfigs; r=Fallen
https://hg.mozilla.org/comm-central/rev/5bb4ac3133c6
Get rid of references to `$commtopsrcdir` in automation mozconfigs; r=Fallen
https://hg.mozilla.org/comm-central/rev/fa2a77a48a22
Get rid of references to mozconfig.comm-support in thunderbird; r=Fallen
https://hg.mozilla.org/comm-central/rev/88f7e0f87f29
Remove unused tooltool manifests; r=Fallen
Assignee

Comment 93

Last year
(In reply to Frank-Rainer Grahl (:frg) from comment #91)
> > IIUC after these patches it won't be possible to build with comm-central as topsrcdir?
> 
> Seems to be only mail/config which is only used in automation. Local builds
> should still work fine.

This is correct.

(In reply to Philipp Kewisch [:Fallen]  from comment #90)
> [...] we need to migrate developers over, or at least provide
> something like client.py that does the checkouts.

That being said, I think that migrating people to the new layout *now* woud be worth while. I anticipate that TB 60 will ship with source packages in the new format; and I know that the mozilla build peers would like to remove the special cases to handle the c-c topdir layout in mozbuild/mach.
Flags: needinfo?(mozilla)
Assignee

Updated

Last year
Duplicate of this bug: ccrework
Assignee

Comment 95

Last year
comm-central builds are exclusively built this way, and soon releases will be as well.
Status: ASSIGNED → RESOLVED
Closed: Last year
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.