#11959: Remove the necessity to set SAGE_PARALLEL_SPKG_BUILD
------------------------------+---------------------------------------------
   Reporter:  jhpalmieri      |          Owner:  GeorgSWeber                    
        
       Type:  enhancement     |         Status:  needs_work                     
        
   Priority:  minor           |      Milestone:  sage-4.7.3                     
        
  Component:  build           |       Keywords:  SAGE_PARALLEL_SPKG_BUILD MAKE 
-j --jobs
Work_issues:                  |       Upstream:  N/A                            
        
   Reviewer:  Leif Leonhardy  |         Author:  John Palmieri                  
        
     Merged:                  |   Dependencies:                                 
        
------------------------------+---------------------------------------------

Comment(by jhpalmieri):

 The `2.5` number for `-l` came straight from the GNU make man page.

 Regarding variables in the Makefile, I saw this sentence in the man page:
 "When make runs a recipe, variables defined in the makefile are placed
 into the environment of each shell." This is a bit misleading, because it
 only exports variables that already came from the environment, so I saw
 that my setting of SAGE_PARALLEL_SPKG_BUILD=yes was being overridden when
 I ran "make build-serial".  I see now that if this variable is unset, then
 "make build-serial" doesn't do what it should.  Why can't I just do
 {{{
 build-serial: export SAGE_PARALLEL_SPKG_BUILD = no
 build-serial: build
 }}}
 Or is this too specific to GNU make?  (Will our makefiles work without GNU
 make anyway?)

 For grep, I like the output from `grep -l ...`, so I'll use that.

 > Do we mention LC_ALL=C (or e.g. LC_MESSAGES=en_US.utf8) for submitting
 error logs?

 I don't think so, and I'm not planning to add anything about it.

 Re `TROUBLESHOOTING.txt`: we could instead have a structure more like many
 GNU projects: a boilerplate README and then a file INSTALL with specific
 instructions.

 While we're off-topic: Is the top-level `install.log` any use as it is
 right now?  It would be better if it had just summary information:
 {{{
 All environment variables ...
 }}}
 and then lines like the following (probably intermixed for the different
 spkgs):
 {{{
 [time] Started building python-...spkg; keeping a log in
 spkg/logs/python-...log
 [time] Successfully installed python-....
 }}}
 or
 {{{
 [time] Started building python-...spkg; keeping a log in
 spkg/logs/python-...log
 [time] Error building python-...; see spkg/logs/python-... for a full log
 }}}
 or
 {{{
 [time] Started building python-...spkg; keeping a log in
 spkg/logs/python-...log
 [time] Error testing python...; see spkg/logs/python-... for a full log
 }}}
 And then at the end
 {{{
 real    106m26.143s
 user    147m9.046s
 sys     21m31.998s

 Sage build/upgrade complete!
 ...
 }}}
 How hard would that be?

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11959#comment:22>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica, 
and MATLAB

-- 
You received this message because you are subscribed to the Google Groups 
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/sage-trac?hl=en.

Reply via email to