The default bug view has changed. See this FAQ.

mach build a comm-central app (SM, TB) throws exception at the end

RESOLVED WORKSFORME

Status

()

Core
Build Config
RESOLVED WORKSFORME
4 years ago
a year ago

People

(Reporter: InvisibleSmiley, Assigned: maxli)

Tracking

Trunk
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [mach])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
The exception I get (see below) is similar to the one mentioned on bug 854057, but this bug here is about a special case, namely building a comm-central app (SM, TB).

The output I got was:

---------------------------
We know it took a while, but your build finally finished successfully!
Error running mach:

    ['build']

The error occurred in code that was called by the mach command. This is either
a bug in the called code itself or in the way that mach is calling it.

You should consider filing a bug for this issue.

If filing a bug, please include the full output of mach, including this error
message.

The details of the failure are as follows:

Exception: Binary expected at e:/mozilla-src/seamonkey-central\dist\bin\seamonkey.exe does not exist.

  File "e:\mozilla-src\comm-central\mozilla\python/mozbuild/mozbuild/mach_commands.py", line 137, in build
    app_path = self.get_binary_path('app')
  File "e:\mozilla-src\comm-central\mozilla\python/mozbuild\mozbuild\base.py", line 161, in get_binary_path
    raise Exception('Binary expected at %s does not exist.' % path)
---------------------------

The problem is that when building a comm-central app (SM, TB), the "dist" directory is below the "mozilla" directory, not directly below the OBJDIR.

I understand that the whole "get the app binary path" exercise here is solely to display a helpful comment. Now if fixing it is considered too much effort, I'd like to at least not get an exception that at first glance suggests that something during the build process failed.

Comment 1

4 years ago
mach and comm-central aren't exactly well-integrated. Although, I suspect the issue here is the "find the binary logic" doesn't properly resolve the equivalent of $(DIST).
Component: mach → Build Config
Whiteboard: [mach]
Duplicate of this bug: 876083
(Reporter)

Comment 3

4 years ago
Since nothing's moving here I developed a workaround. The error message is a direct result of the fact that dist/ is located below mozilla/ when building a c-c app. Hence, just create a symlink. Unfortunately, MSYS "ln -s" on Windows doesn't create a symlink but creates a copy. "cmd" to the rescue:

mkdir -p $OBJDIR && cd $OBJDIR && cmd /c 'mklink /j dist mozilla\dist'

If you invoke the above directly before running mach, you're good (provided you're on Windows 7 with an NTFS filesystem). Initially the junction will point nowhere, but once mozilla/dist/ is created, it will automatically point to the target.

NB: I don't know whether the MSYS tools will be able to remove the junction. My "make distclean" command is the following:

WIN_OBJDIR=$(cygpath -w "$OBJDIR")
cmd /c "rmdir /s /q $WIN_OBJDIR"
Josh, were you looking into integrating mach and comm-central, or am I mis-remembering things?
(In reply to Blake Winton (:bwinton) from comment #4)
> Josh, were you looking into integrating mach and comm-central, or am I
> mis-remembering things?

I've mostly been working on the moz.build stuff, not mach.
(Assignee)

Updated

4 years ago
Duplicate of this bug: 880981
Duplicate of this bug: 892473
(Assignee)

Comment 8

4 years ago
Created attachment 775249 [details] [diff] [review]
Patch
Assignee: nobody → maxli
Attachment #775249 - Flags: review?(gps)
Comment on attachment 775249 [details] [diff] [review]
Patch

I dislike this patch because it's hardcoding by app name, which is going to break this again when bug 648979 hits (which I'm hoping to finish off by the end of the month). I might suggest checking to see if dist exists and using mozilla/dist if it doesn't, but I'm not sure that is feasible.
Attachment #775249 - Flags: feedback-
Comment on attachment 775249 [details] [diff] [review]
Patch

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

I believe that the comm-central build system defines a variable (is it MOZILLA_DIR?) that denotes where the main m-c build system output resides. A solution should use this instead of a one-off defining out-of-tree applications.

My guess is jcranmer knows what I'm talking about...
Attachment #775249 - Flags: review?(gps) → review-
(In reply to Gregory Szorc [:gps] from comment #10)
> Comment on attachment 775249 [details] [diff] [review]
> Patch
> 
> Review of attachment 775249 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I believe that the comm-central build system defines a variable (is it
> MOZILLA_DIR?) that denotes where the main m-c build system output resides. A
> solution should use this instead of a one-off defining out-of-tree
> applications.
> 
> My guess is jcranmer knows what I'm talking about...

MOZILLA_SRCDIR is the name of the variable I think you're looking for, but that's only defined in config/config.mk or something like that. The only sign in mozbuild that it's comm-central that's going on is the presence of COMM_BUILD.
Duplicate of this bug: 920506

Comment 13

4 years ago
FYI, I am seeing the same error on OSX 10.8.5. Creating a symbolic link $OBJDIR/dist to $OBJDIR/mozilla/dist as suggested in comment 3 worked.

Comment 14

4 years ago
FYI, I updated https://developer.mozilla.org/en-US/docs/Simple_Thunderbird_build to let new folks know they can ignore this error.
Duplicate of this bug: 973336

Comment 16

3 years ago
Problems seems fixed. After running |mach build| there is no error message displayed to me and running |mach run| launches ./obj-i686-pc-mingw32/dist/bin/thunderbird.exe.

Comment 17

a year ago
Reporter, do you still observe the error? For me it works as stated last year in comment 16.
Flags: needinfo?(jh)
(Reporter)

Comment 18

a year ago
(In reply to Stefan Sitter from comment #17)
> Reporter, do you still observe the error?

I haven't built for quite some time. Retried now, ran into bug 1229073, but with the first patch from there it worked. :-) Closing as WFM.
Status: NEW → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(jh)
Resolution: --- → WORKSFORME

Comment 19

a year ago
So, where exactly was this fixed then?
You need to log in before you can comment on or make changes to this bug.