GEOS-5 Checkout and Build Instructions: Difference between revisions

Line 64:

Note that the string following "group_list=" is your group-id code. It's the project that gets charged for the computer time you use. If you're not on "g0604" that's okay, the queue system will let you know and it won't start your job. To find out which group you belong to, issue the following command:

% getsponsor

and you'll get a table of sponsor codes available to you. Enter one of those in the group_list string and try again.

and you'll get a table of sponsor codes available to you. Enter one of those codes as the group_list string and try again.

Wait, what have we done here? We've started an interactive queue (interactive in the sense that you have a command line) where we've now go 8 cpus allocated to us (and us alone!) for the next 12 hours. We can use all those 8 cpus to speed up our build as follows:

% gmake --jobs=8 pinstall

The syntax here is that "--jobs=" specifies the number of cpus to use (up to the 8 we've requested in our queue) and "pinstall" means to do a parallel install. Don't worry, the result should be the same as "gmake install" above but take a fraction of the time.

What if something goes wrong? Sometimes the build just doesn't go right. It's useful to save the output that scrolls by on the screen to a file so you can analyze it later. Modify any of the build examples above as follows to capture the text to a file called "make.log":

% gmake --jobs=8 pinstall |& tee make.log

and now you have a record of how the build progressed. When the build completes (successfully or otherwise) you can analyze the build results by issuing the following command:

% Config/gmh.pl -v make.log

and you'll be given a list of what compiled and didn't, which will hopefull allow you to go in and find any problems.

@@ Line 64: / Line 64: @@
 Note that the string following "group_list=" is your group-id code.  It's the project that gets charged for the computer time you use.  If you're not on "g0604" that's okay, the queue system will let you know and it won't start your job.  To find out which group you belong to, issue the following command:
   % getsponsor
-and you'll get a table of sponsor codes available to you.  Enter one of those in the group_list string and try again.
+and you'll get a table of sponsor codes available to you.  Enter one of those codes as the group_list string and try again.
+Wait, what have we done here?  We've started an interactive queue (interactive in the sense that you have a command line) where we've now go 8 cpus allocated to us (and us alone!) for the next 12 hours.  We can use all those 8 cpus to speed up our build as follows:
+ % gmake --jobs=8 pinstall
+The syntax here is that "--jobs=" specifies the number of cpus to use (up to the 8 we've requested in our queue) and "pinstall" means to do a parallel install.  Don't worry, the result should be the same as "gmake install" above but take a fraction of the time.
+What if something goes wrong?  Sometimes the build just doesn't go right.  It's useful to save the output that scrolls by on the screen to a file so you can analyze it later.  Modify any of the build examples above as follows to capture the text to a file called "make.log":
+ % gmake --jobs=8 pinstall |& tee make.log
+and now you have a record of how the build progressed.  When the build completes (successfully or otherwise) you can analyze the build results by issuing the following command:
+ % Config/gmh.pl -v make.log
+and you'll be given a list of what compiled and didn't, which will hopefull allow you to go in and find any problems.