Provide info for running the binary, tests

RESOLVED FIXED in mozilla22

Status

()

Core
Build Config
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: humph, Assigned: gps)

Tracking

(Blocks: 2 bugs)

Trunk
mozilla22
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
OS: Mac OS X → All
Hardware: x86 → All
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.

Updated

7 years ago
Whiteboard: [good first bug][contrib-engagement]
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

Comment 10

6 years ago
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.

Comment 12

6 years ago
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

6 years ago
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 ?

Updated

6 years ago
Depends on: 650756

Updated

6 years ago
No longer depends on: 650756

Comment 14

6 years ago
(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.

Comment 16

6 years ago
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 ?

Updated

6 years ago
Blocks: 652716
Whiteboard: [good first bug][contrib-engagement] → [good first bug]

Updated

6 years ago
Blocks: 652719

Updated

6 years ago
No longer blocks: 652716
Dropping a link to the correct wiki page in the URL field.
Whiteboard: [good first bug] → [mentor=ted][lang=make]

Comment 18

5 years ago
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 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.
Attachment #642988 - Flags: review?(ted.mielczarek)
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.
(Assignee)

Comment 22

5 years ago
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.
Assignee: nobody → gps
Status: NEW → ASSIGNED
Attachment #717291 - Flags: review?(ted)
(Assignee)

Updated

5 years ago
Blocks: 844292
(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?
(Assignee)

Comment 25

5 years ago
(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.
(Assignee)

Comment 26

5 years ago
Bug 784841 landed code to mozbuild that loads config.status. We should rebase this patch to use that.
(Assignee)

Comment 27

5 years ago
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.
Attachment #642988 - Attachment is obsolete: true
Attachment #717291 - Attachment is obsolete: true
Attachment #642988 - Flags: review?(ted)
Attachment #717291 - Flags: review?(ted)
Attachment #720861 - Flags: review?(ted)
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. :)
Attachment #720861 - Flags: review?(ted) → review+
Oh, also! The URL from comment 6 / comment 9!
(Assignee)

Comment 30

5 years ago
(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!
(Assignee)

Comment 31

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/432f32e842dd
Whiteboard: [mentor=ted][lang=make]
Target Milestone: --- → mozilla22
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
(Assignee)

Comment 33

5 years ago
Our build infra confounds me. "It works locally!"
Target Milestone: mozilla22 → ---
could this be an issue with mozharness?
(Assignee)

Comment 35

5 years ago
(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...
(Assignee)

Updated

5 years ago
Blocks: 853954
(Assignee)

Comment 36

5 years ago
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.
Attachment #720861 - Attachment is obsolete: true
Attachment #728347 - Flags: review?(ted)
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()".
Attachment #728347 - Flags: review?(ted) → review+
(Assignee)

Comment 38

5 years ago
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.
(Assignee)

Comment 39

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/d38a69107bd4
Target Milestone: --- → mozilla22
(Assignee)

Comment 40

5 years ago
Bustage fix (silly Python error present on non-Darwin platforms). Derp.

https://hg.mozilla.org/integration/mozilla-inbound/rev/4c41e7a015b9
(Assignee)

Comment 41

5 years ago
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
(Assignee)

Updated

5 years ago
Blocks: 854057
https://hg.mozilla.org/mozilla-central/rev/d38a69107bd4
https://hg.mozilla.org/mozilla-central/rev/4c41e7a015b9
https://hg.mozilla.org/mozilla-central/rev/be8b1f1c9edf
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Just noticed this for the first time:

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

I am _delighted_. <3
Blocks: 841445
Blocks: 855262
Blocks: 857383
Blocks: 863409
You need to log in before you can comment on or make changes to this bug.