Last Comment Bug 648681 - Provide info for running the binary, tests
: Provide info for running the binary, tests
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Build Config (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla22
Assigned To: Gregory Szorc [:gps]
:
: Gregory Szorc [:gps]
Mentors:
https://developer.mozilla.org/en/Deve...
Depends on:
Blocks: contrib-engagement 853954 841445 844292 854057 855262 857383 863409
  Show dependency treegraph
 
Reported: 2011-04-08 16:51 PDT by David Humphrey (:humph)
Modified: 2013-04-18 13:01 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Outputs binary location at the end of the build process. (1.90 KB, patch)
2012-07-17 09:10 PDT, Steffi
no flags Details | Diff | Splinter Review
Print path to binary when building with mach, v1 (7.87 KB, patch)
2013-02-22 13:22 PST, Gregory Szorc [:gps]
no flags Details | Diff | Splinter Review
Print path to binary when building with mach, v2 (8.25 KB, patch)
2013-03-04 13:27 PST, Gregory Szorc [:gps]
ted: review+
Details | Diff | Splinter Review
Print path to binary when building with mach, v3 (9.98 KB, patch)
2013-03-22 12:09 PDT, Gregory Szorc [:gps]
ted: review+
Details | Diff | Splinter Review

Description David Humphrey (:humph) 2011-04-08 16:51:14 PDT
When a WebKit build finishes, it prints the following:

** BUILD SUCCEEDED **


===========================================================
 WebKit is now built (17m:40s). 
 To run Safari with this newly-built code, use the
 "Tools/Scripts/run-safari" script.
===========================================================


I think we should steal something like this.  Ted suggests:

19:21 < ted> "To run Firefox run $DIST/bin/firefox.exe" or whatever
19:22 < ted> would actually be really useful on mac where you have to run 
             dist/Minefield.app/Contents/MacOS/firefox-bin

Might be nice to provide some URLs to info on running tests too?  This is especially helpful in the Mac case, since you have to run from the bundle.
Comment 1 Tony Mechelynck [:tonymec] 2011-04-09 00:31:19 PDT
The "recommended" way to try a new build is to "gmake -C {objdir} package" (replacing {objdir} by the path of your objdir) then install at a nonconflicting location just like you would install a nightly from Mozilla. (For Windows, you can "gmake -C {objdir} installer" instead to build an .installer.exe)

This is well documented, see https://developer.mozilla.org/en/Build_and_Install#Installing_Your_Build

I suggest WONTFIX.
Comment 2 Ted Mielczarek [:ted.mielczarek] 2011-04-09 05:58:47 PDT
Uh, I told humph to file this bug, I'm not going to WONTFIX it. I want this. Just because we have things in a wiki doc doesn't mean that people will read them.
Comment 3 :Ehsan Akhgari 2011-04-11 11:54:44 PDT
FWIW, this is the first time that I'm hearing that the recommended way to run our builds is to use the packaged version, in the past 4.x years that I've been running my builds!

I think a patch which implements comment 0 will fill my eyes with tears.  Happy tears.  Seriously.  /me wants.
Comment 4 Tony Mechelynck [:tonymec] 2011-04-11 22:15:05 PDT
(In reply to comment #3)
> FWIW, this is the first time that I'm hearing that the recommended way to run
> our builds is to use the packaged version, in the past 4.x years that I've been
> running my builds!

On rereading the doc, it's ambiguously worded:
https://developer.mozilla.org/en/Build_and_Install#Running_Your_New_Build
«It is possible to run your new build directly from the directory in which it was built. However, the build directory may contain symlinks into the build tree; you must run the installation/packaging step to produce a standalone build which can be shared or moved.»
This sounds to me like saying that running the packaging step is less hassle, since it produces something which you can install anywhere just like the (familiar) Mozilla nightlies. You might have understood it otherwise.
Comment 5 :Ehsan Akhgari 2011-04-12 14:53:35 PDT
(In reply to comment #4)
> (In reply to comment #3)
> > FWIW, this is the first time that I'm hearing that the recommended way to run
> > our builds is to use the packaged version, in the past 4.x years that I've been
> > running my builds!
> 
> On rereading the doc, it's ambiguously worded:
> https://developer.mozilla.org/en/Build_and_Install#Running_Your_New_Build
> «It is possible to run your new build directly from the directory in which it
> was built. However, the build directory may contain symlinks into the build
> tree; you must run the installation/packaging step to produce a standalone
> build which can be shared or moved.»
> This sounds to me like saying that running the packaging step is less hassle,
> since it produces something which you can install anywhere just like the
> (familiar) Mozilla nightlies. You might have understood it otherwise.

Oh no, that is completely true.  It's just that most people who compile the code don't need to move it to other machines.

That said, I think we can also print a line asking people to run make package if they want to move the build to another machine.
Comment 6 Ted Mielczarek [:ted.mielczarek] 2011-04-12 16:38:42 PDT
I think the ideal fix for this bug would print, at the end of the build something like:

"Your build was successful! :)
To run your newly-built Firefox, use:
/path/to/firefox (this should print out the full path to the resulting binary, including the Contents/MacOS bit on Mac)
For more information on what to do now, see:
http://developer.mozilla.org/So_You_Just_Built_Firefox"

and we can stick more useful details there, like links to how to package and distribute your build, how to run tests, etc.
Comment 7 :Ehsan Akhgari 2011-04-12 18:40:44 PDT
Again, my eyes are full of happy tears!
Comment 8 Tony Mechelynck [:tonymec] 2011-04-13 01:09:40 PDT
(In reply to comment #5)
[...]
> That said, I think we can also print a line asking people to run make package
> if they want to move the build to another machine.

Or even to another directory (where, for instance, it won't be clobbered by the next build run).
Comment 9 Ted Mielczarek [:ted.mielczarek] 2011-04-13 04:49:32 PDT
I created the stub page I posited in comment 6, if someone wants to start populating it:
https://developer.mozilla.org/en/So_You_Just_Built_Firefox
Comment 10 JVD 2011-04-16 13:27:26 PDT
I'm going to develop a replacement for the "installer run" / "make install" phase on Linux for use on my own system, which uses ONLY GNU make(1) 
and GNU bash(1) - these would have to be hard dependencies, but you'll
find they are hard dependencies of the GNU gcc / binutils toolchain also.

So after "make" succeeds, "make install", if on a Linux platform, would run 
${topsrcdir}/${MOZ_APP}/make_install.sh to generate a "make install" Makefile,
which is stored as ${MOZ_OBJDIR}/${MOZ_APP}/Makefile.install, and consists
ONLY of make dependency statements to store $MOZ_APP newly built objects
under $(DESTDIR)/$(PREFIX)/{$BINDIR,$LIBDIR,$DATAROOTDIR,$DOCDIR,...} etc,
if $MOZ_USE_SYSTEM_TREE is set, else under ${DESTDIR}/${PREFIX}/${LIBDIR}/${MOZ_APP}-${MOZ_APP_VERSION} as currently if not set .

If anyone thinks that might help fix this bug, I'll thoroughly test it and
post it as a patch here.
Comment 11 Ted Mielczarek [:ted.mielczarek] 2011-04-16 16:01:59 PDT
I don't think that's really related. This bug is just about providing next steps for users after a build completes.
Comment 12 JVD 2011-04-16 16:23:54 PDT
Hi Ted -
I was responding to Paul's email :
> Awesome. I'd personally love it if you fixed:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=648701
> https://bugzilla.mozilla.org/show_bug.cgi?id=648681
>
> I've CCed Ted, our build system maintainer. While I suspect that a ...
Was this the wrong bug ? sorry - I'll try to get the comment moved ...
I also tried to update the webpage you attached to this bug report with
an html file attachment: 

bugzilla, I hope you recognize this as HTML :

<html>
<head>
<title> And If, like me, you&lsquo;re on Linux :
</title>
</head>
<body>
<ol>
<li><b>BEFORE you do :</b><br>/
<pre> $ make clean
</pre>
<ol> Check:
<li> That the firefox executable (actually xulrunner-stub) exists and links correctly:
<pre>
$ ldd /usr/lib64/firefox-4.0b13pre/firefox
        linux-vdso.so.1 =>  (0x00007fff3bfd7000)
        libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f209030e000)
        libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f209010a000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f208fe07000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f208fb85000)
        libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f208f970000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f208f5e8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f209052b000)
</pre> 
</li>
<li> That the firefox executable's libxul.so exists and links correctly:
<pre>
$ $ ldd /usr/lib64/firefox-4.0b13pre/libxul.so                                                                                                                          
        linux-vdso.so.1 =>  (0x00007fff40992000)                                                                                                                      
        libpthread.so.0 => /usr/lib64/libpthread.so.0 (0x00007f4b8446d000)                                                                                            
        libmozsqlite3.so => /usr/lib64/nspr/libmozsqlite3.so (0x00007f4b8419f000)                                                                                     
        libsmime3.so => /usr/lib64/nspr/libsmime3.so (0x00007f4b83f67000)                                                                                             
        libssl3.so => /usr/lib64/nspr/libssl3.so (0x00007f4b83d13000)                                                                                                 
        libnss3.so => /usr/lib64/libnss3.so (0x00007f4b8398a000)                                                                                                      
        libnssutil3.so => /usr/lib64/nspr/libnssutil3.so (0x00007f4b83762000)                                                                                         
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f4b83558000)                                                                                            
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f4b832d5000)                                                                                          
        libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f4b830a1000)                                                                                      
        libasound.so.2 => /usr/lib64/libasound.so.2 (0x00007f4b82dc0000)                                                                                              
        librt.so.1 => /lib64/librt.so.1 (0x00007f4b82ba5000)                                                                                                          
        libplds4.so => /usr/lib64/nspr/libplds4.so (0x00007f4b829a1000)                                                                                               
        libplc4.so => /usr/lib64/nspr/libplc4.so (0x00007f4b8279d000)                                                                                                 
        libnspr4.so => /usr/lib64/nspr/libnspr4.so (0x00007f4b82558000)                                                                                               
        libdl.so.2 => /usr/lib64/libdl.so.2 (0x00007f4b82353000)                                                                                                      
        libmozalloc.so => /usr/lib64/nspr/libmozalloc.so (0x00007f4b82151000)                                                                                         
        libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f4b81f0e000)                                                                                              
        libdbus-glib-1.so.2 => /usr/lib64/libdbus-glib-1.so.2 (0x00007f4b81cec000)                                                                                    
        libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007f4b81a9e000)                                                                                    
        libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007f4b8189a000)                                                                                    
        libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007f4b815af000)                                                                                          
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f4b81274000)                                                                                                    
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f4b81062000)                                                                                                  
        libpangoft2-1.0.so.0 => /usr/lib64/libpangoft2-1.0.so.0 (0x00007f4b80e36000)                                                                                  
        libpangocairo-1.0.so.0 => /usr/lib64/libpangocairo-1.0.so.0 (0x00007f4b80c2a000)                                                                              
        libpango-1.0.so.0 => /usr/lib64/libpango-1.0.so.0 (0x00007f4b809e0000)                                                                                        
        libcairo.so.2 => /usr/lib64/libcairo.so.2 (0x00007f4b806db000)
        libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007f4b804d8000)
        libgtk-x11-2.0.so.0 => /usr/lib64/libgtk-x11-2.0.so.0 (0x00007f4b7fea1000)
        libatk-1.0.so.0 => /usr/lib64/libatk-1.0.so.0 (0x00007f4b7fc80000)
        libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007f4b7f959000)
        libgdk-x11-2.0.so.0 => /usr/lib64/libgdk-x11-2.0.so.0 (0x00007f4b7f6a6000)
        libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007f4b7f487000)
        libXt.so.6 => /usr/lib64/libXt.so.6 (0x00007f4b7f224000)
        libz.so.1 => /usr/lib64/libz.so.1 (0x00007f4b7f00c000)
        libbz2.so.1.0 => /usr/lib64/libbz2.so.1.0 (0x00007f4b7edfc000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f4b7eaf9000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f4b7e877000)
        libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f4b7e661000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f4b7e2d9000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f4b86ce2000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f4b7e0ba000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f4b7deb7000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f4b7dcb2000)
        libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f4b7da8d000)
        libiconv.so.2 => /usr/lib64/libiconv.so.2 (0x00007f4b7d7ac000)
        libpcre.so.0 => /usr/lib64/libpcre.so.0 (0x00007f4b7d570000)
        libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x00007f4b7d2fd000)
        libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007f4b7d0e2000)
        libpng15.so.15 => /usr/lib64/libpng15.so.15 (0x00007f4b7cebd000)
        libxcb-dri2.so.0 => /usr/lib64/libxcb-dri2.so.0 (0x00007f4b7ccba000)
        libudev.so.0 => /lib64/libudev.so.0 (0x00007f4b7caab000)
        libxcb-shm.so.0 => /usr/lib64/libxcb-shm.so.0 (0x00007f4b7c8a9000)
        libX11-xcb.so.1 => /usr/lib64/libX11-xcb.so.1 (0x00007f4b7c6a8000)
        libxcb-render.so.0 => /usr/lib64/libxcb-render.so.0 (0x00007f4b7c49e000)
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f4b7c21f000)
        libXinerama.so.1 => /usr/lib64/libXinerama.so.1 (0x00007f4b7c01c000)
        libXi.so.6 => /usr/lib64/libXi.so.6 (0x00007f4b7be0e000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f4b7bc06000)
        libXcursor.so.1 => /usr/lib64/libXcursor.so.1 (0x00007f4b7b9fb000)
        libXcomposite.so.1 => /usr/lib64/libXcomposite.so.1 (0x00007f4b7b7f9000)
        libXdamage.so.1 => /usr/lib64/libXdamage.so.1 (0x00007f4b7b5f7000)
        libXfixes.so.3 => /usr/lib64/libXfixes.so.3 (0x00007f4b7b3f0000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f4b7b1d9000)
        libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007f4b7afd1000)
        libuuid.so.1 => //lib64/libuuid.so.1 (0x00007f4b7adcd000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007f4b7abb3000)
        libxcb-xfixes.so.0 => /usr/lib64/libxcb-xfixes.so.0 (0x00007f4b7a9ac000)
        libxcb-shape.so.0 => /usr/lib64/libxcb-shape.so.0 (0x00007f4b7a7a9000)
        libdrm.so.2 => /usr/lib64/libdrm.so.2 (0x00007f4b7a59d000)
        libXxf86vm.so.1 => /usr/lib64/libXxf86vm.so.1 (0x00007f4b7a398000)
</pre> 
</li>
<li>
</ol>
</li>
<li>
<i> shall I continue ? ... </i>
</li>
</ol>
</body>
</html>
Comment 13 JVD 2011-04-16 16:26:39 PDT
As you can see, I've got xulrunner and firefox linking to the SAME installed
instances of /usr/lib64/{nspr,nss}*  .

WHY, OH WHY did the installer first try to create two copies of libxul.so 
before finding it had insufficient disk space and crashing ?
Comment 14 Paul Biggar 2011-04-18 05:15:23 PDT
(In reply to comment #6)
> "Your build was successful! :)
> To run your newly-built Firefox, use:
> /path/to/firefox (this should print out the full path to the resulting binary,
> including the Contents/MacOS bit on Mac)
> For more information on what to do now, see:
> http://developer.mozilla.org/So_You_Just_Built_Firefox"
> 
> and we can stick more useful details there, like links to how to package and
> distribute your build, how to run tests, etc.

I'm a little wary of directing people back to the internet instead of putting the information directly in front of them, but I think that page is a good start.
Comment 15 Ted Mielczarek [:ted.mielczarek] 2011-04-18 08:32:24 PDT
I'm not. We already do this in error messages in configure, and I think it's much better than trying to jam a lot of info in there. Plus we can easily edit it without having to get review or land things in m-c.
Comment 16 JVD 2011-04-18 10:05:10 PDT
Hi Ted, Paul : did you want me to fill more info in on that page I submitted ?
How do you get the Wiki page to recognize an "attached file" as HTML ?
Comment 17 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-07-09 12:59:45 PDT
Dropping a link to the correct wiki page in the URL field.
Comment 18 Steffi 2012-07-17 09:10:51 PDT
Created attachment 642988 [details] [diff] [review]
Outputs binary location at the end of the build process.

This is my first proposed patch ever - I am not completely sure whether the change is in the right file and I added two more ideas for changes as comments in the code.
Comment 19 Ted Mielczarek [:ted.mielczarek] 2012-07-17 09:54:16 PDT
Comment on attachment 642988 [details] [diff] [review]
Outputs binary location at the end of the build process.

Thanks for the patch! I'm putting it in my review queue so I remember to take a look at it.
Comment 20 Josh Matthews [:jdm] (on vacation until Dec 5) 2012-12-25 08:59:25 PST
Ted, might you find some time to actually look at the patch some time? :)
Comment 21 Josh Matthews [:jdm] (on vacation until Dec 5) 2013-02-05 03:03:27 PST
Now that we use and recommend mach for all building, http://hg.mozilla.org/mozilla-central/annotate/2a8e243711a9/python/mozbuild/mozbuild/mach_commands.py#l138 would be a good place to put this information.
Comment 22 Gregory Szorc [:gps] 2013-02-22 13:22:22 PST
Created attachment 717291 [details] [diff] [review]
Print path to binary when building with mach, v1

There are a few parts to this patch. I was too lazy to split them up.

1) buildconfig integration with mozbuild. I essentially had to copy parts of buildconfig.py. We can probably refactor buildconfig.py later, if we so desire.

2) Add a get_binary_path() method to base.py. It needs variables from config.status to work, which is why #1 was added. I copied some of the logic from the existing .mk file. Do we care about Camino?

3) Change what is printed after |mach build|. The meat of this bug. I don't really care for client.mk.

Once this lands, we can implement |mach run| in bug 841445.
Comment 23 Blair McBride [:Unfocused] (UNAVAILABLE) 2013-02-23 20:18:15 PST
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #6)
> To run your newly-built Firefox, use:
> /path/to/firefox (this should print out the full path to the resulting
> binary, including the Contents/MacOS bit on Mac)

Why the bundle contents as well on Mac? Usually its best for most people to run the .app (via |open whatever.app|).
Comment 24 Ted Mielczarek [:ted.mielczarek] 2013-02-24 10:13:43 PST
If you're running from the commandline, what difference does it make?
Comment 25 Gregory Szorc [:gps] 2013-02-24 10:22:22 PST
(In reply to Blair McBride [:Unfocused] (Back from the dead. Mostly.) from comment #23)
> (In reply to Ted Mielczarek [:ted.mielczarek] from comment #6)
> > To run your newly-built Firefox, use:
> > /path/to/firefox (this should print out the full path to the resulting
> > binary, including the Contents/MacOS bit on Mac)
> 
> Why the bundle contents as well on Mac? Usually its best for most people to
> run the .app (via |open whatever.app|).

Another slight difference is the default detaching behavior of open. Unless you pass -W to open, the program essentially detaches from the terminal. ctrl+c will have no effect. It's also hard to get multiple instances of the app (you need to pass -n to open). I think developers would prefer the traditional terminal behavior when they launch Contents/MacOS/firefox as opposed to open.
Comment 26 Gregory Szorc [:gps] 2013-02-28 07:06:26 PST
Bug 784841 landed code to mozbuild that loads config.status. We should rebase this patch to use that.
Comment 27 Gregory Szorc [:gps] 2013-03-04 13:27:18 PST
Created attachment 720861 [details] [diff] [review]
Print path to binary when building with mach, v2

Rebased on top of config.status loading code added in bug 784841.

People are clamoring for |mach run|. This blocks.
Comment 28 Ted Mielczarek [:ted.mielczarek] 2013-03-08 05:21:03 PST
Comment on attachment 720861 [details] [diff] [review]
Print path to binary when building with mach, v2

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

r+ with a few comments

::: python/mozbuild/mozbuild/base.py
@@ +134,5 @@
> +        """
> +
> +        substs = self.substs
> +
> +        stem = self.distdir

We have at least one script in the tree that wants to run the binary from the staged package bits (the PGO profiling script):
http://mxr.mozilla.org/mozilla-central/source/build/pgo/Makefile.in#20

It would be nice to support getting that as well.

@@ +142,5 @@
> +
> +        leaf = None
> +
> +        if what == 'xulapp':
> +            leaf = substs['MOZ_APP_NAME'] + substs['BIN_SUFFIX']

Feels like the "what" parameter should be optional and default to the application. "xulapp" is a little clunky for a name.

@@ +144,5 @@
> +
> +        if what == 'xulapp':
> +            leaf = substs['MOZ_APP_NAME'] + substs['BIN_SUFFIX']
> +        elif what == 'xpcshell':
> +            leaf = 'xpcshell'

Interestingly, I don't think anything in the tree bothers to run xpcshell from inside the mac bundle currently. I don't know that it matters one way or the other.

::: python/mozbuild/mozbuild/mach_commands.py
@@ +137,5 @@
>  
> +        if not status:
> +            print('Finished building. Built files are in %s' % self.topobjdir)
> +            app_path = self.get_binary_path('xulapp')
> +            print('The main application binary is %s' % app_path)

I would phrase this as "You can run the binary you just built as: %s".

Also maybe we can put a fun message in here ala comment 6? Use your judgement. :)
Comment 29 Ted Mielczarek [:ted.mielczarek] 2013-03-08 05:22:01 PST
Oh, also! The URL from comment 6 / comment 9!
Comment 30 Gregory Szorc [:gps] 2013-03-08 08:29:51 PST
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #28)
> ::: python/mozbuild/mozbuild/base.py
> @@ +134,5 @@
> > +        """
> > +
> > +        substs = self.substs
> > +
> > +        stem = self.distdir
> 
> We have at least one script in the tree that wants to run the binary from
> the staged package bits (the PGO profiling script):
> http://mxr.mozilla.org/mozilla-central/source/build/pgo/Makefile.in#20
> 
> It would be nice to support getting that as well.

Meh. Follow-up.

> @@ +142,5 @@
> > +
> > +        leaf = None
> > +
> > +        if what == 'xulapp':
> > +            leaf = substs['MOZ_APP_NAME'] + substs['BIN_SUFFIX']
> 
> Feels like the "what" parameter should be optional and default to the
> application. "xulapp" is a little clunky for a name.

Will change 'xulapp' to 'app' and make 'app' the default value.

> @@ +144,5 @@
> > +
> > +        if what == 'xulapp':
> > +            leaf = substs['MOZ_APP_NAME'] + substs['BIN_SUFFIX']
> > +        elif what == 'xpcshell':
> > +            leaf = 'xpcshell'
> 
> Interestingly, I don't think anything in the tree bothers to run xpcshell
> from inside the mac bundle currently. I don't know that it matters one way
> or the other.

I don't think it matters, so meh.

> ::: python/mozbuild/mozbuild/mach_commands.py
> @@ +137,5 @@
> >  
> > +        if not status:
> > +            print('Finished building. Built files are in %s' % self.topobjdir)
> > +            app_path = self.get_binary_path('xulapp')
> > +            print('The main application binary is %s' % app_path)
> 
> I would phrase this as "You can run the binary you just built as: %s".
> 
> Also maybe we can put a fun message in here ala comment 6? Use your
> judgement. :)

Will do!
Comment 32 Ryan VanderMeulen [:RyanVM] 2013-03-08 11:24:26 PST
Backed out for test failures.
https://hg.mozilla.org/integration/mozilla-inbound/rev/77066de4b339

TEST-UNEXPECTED-FAIL | /builds/slave/m-in-l64-d-0000000000000000000/build/python/mozbuild/mozbuild/test/test_base.py | line 62, test_config_environment: config.status not available. Run configure.
TEST-UNEXPECTED-FAIL | /builds/slave/m-in-l64-d-0000000000000000000/build/python/mozbuild/mozbuild/test/test_base.py | line 74, test_get_binary_path: config.status not available. Run configure.
make[1]: *** [run-/builds/slave/m-in-l64-d-0000000000000000000/build/python/mozbuild/mozbuild/test/test_base.py] Error 1
Comment 33 Gregory Szorc [:gps] 2013-03-08 11:40:10 PST
Our build infra confounds me. "It works locally!"
Comment 34 Joel Maher ( :jmaher) 2013-03-22 05:48:39 PDT
could this be an issue with mozharness?
Comment 35 Gregory Szorc [:gps] 2013-03-22 10:15:54 PDT
(In reply to Joel Maher (:jmaher) from comment #34)
> could this be an issue with mozharness?

Possibly. I'm inclined to work around it by coding a test that doesn't rely on the tree being built. Let's see if I can find time today to hash this out...
Comment 36 Gregory Szorc [:gps] 2013-03-22 12:09:27 PDT
Created attachment 728347 [details] [diff] [review]
Print path to binary when building with mach, v3

I removed some bit rot, hacked up the tests, and filed a follow-up to unhack the tests.

I removed config.status locally and the tests executed successfully. Pretty confident this will work.
Comment 37 Ted Mielczarek [:ted.mielczarek] 2013-03-22 12:15:02 PDT
Comment on attachment 728347 [details] [diff] [review]
Print path to binary when building with mach, v3

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

I think as a followup I would like this API to be slightly easier to use, so we could swap out things that are currently using automation.py to find the binary with "from whatever import get_binary_path; app = get_binary_path()".
Comment 38 Gregory Szorc [:gps] 2013-03-22 12:18:10 PDT
I agree. I consider base.py to be a giant hack. Sadly, I/we keep piling things on instead of inventing decent APIs. I'd eventually like to implement a high-level interface to the build system. e.g.

buildsystem = BuildSystem.from_mozconfig(topsrcdir, path_to_mozconfig)
buildsystem = BuildSystem.from_environment(topsrcdir)

buildsystem.get_binary_path()

etc. base.py is close, but not quite.
Comment 40 Gregory Szorc [:gps] 2013-03-22 15:21:03 PDT
Bustage fix (silly Python error present on non-Darwin platforms). Derp.

https://hg.mozilla.org/integration/mozilla-inbound/rev/4c41e7a015b9
Comment 41 Gregory Szorc [:gps] 2013-03-22 15:29:52 PDT
And after that obvious bustage, I found bustage on OS X. So, I just disabled these tests. This code doesn't run as part of the build, so I'm not too worried about the lack of test coverage for the moment. We have bug 853954 on file. We'll figure it out.

https://hg.mozilla.org/integration/mozilla-inbound/rev/be8b1f1c9edf
Comment 43 Justin Dolske [:Dolske] 2013-03-23 17:34:28 PDT
Just noticed this for the first time:

"We know it took a while, but your build finally finished successfully!"

I am _delighted_. <3

Note You need to log in before you can comment on or make changes to this bug.