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.

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.

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.

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.

(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.

(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.

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.

Again, my eyes are full of happy tears!

(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).

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

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.

I don't think that's really related. This bug is just about providing next steps for users after a build completes.

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>

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 ?

(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.

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.

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 ?

Dropping a link to the correct wiki page in the URL field.

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 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.

Ted, might you find some time to actually look at the patch some time? :)

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.

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.

(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|).

If you're running from the commandline, what difference does it make?

(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.

Bug 784841 landed code to mozbuild that loads config.status. We should rebase this patch to use that.

Rebased on top of config.status loading code added in bug 784841. People are clamoring for |mach run|. This blocks.

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. :)

Oh, also! The URL from comment 6 / comment 9!

(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!

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

Our build infra confounds me. "It works locally!"

could this be an issue with mozharness?

(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...

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 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()".

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.

Bustage fix (silly Python error present on non-Darwin platforms). Derp. https://hg.mozilla.org/integration/mozilla-inbound/rev/4c41e7a015b9

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

https://hg.mozilla.org/mozilla-central/rev/d38a69107bd4 https://hg.mozilla.org/mozilla-central/rev/4c41e7a015b9 https://hg.mozilla.org/mozilla-central/rev/be8b1f1c9edf

Just noticed this for the first time: "We know it took a while, but your build finally finished successfully!" I am _delighted_. <3