Re: streamlining build process.

[Ben Sapp]

"John W. Eaton" wrote:
> I applied your patch with a few modifications and checked in the
> changes (diffs appended).
> 

Thanks.  I have compiled from the todays CVS source and it works
great.   

> The main difference from your original changes is that I don't try to
> build the object files from the libcruft directory.  Instead, I let
> make recurse through the libcruft subdirectories to build the objects,
> then I put them all together in the libcruft directory.  This is
> similar to the way things work for creating a shared library version
> of libcruft.  By recursing, we avoid missing any special targets that
> might need to be run in the subdirectories.
>
> One of the advantages of the previous approach has been lost.  Now if
> you run make in a libcruft subdirectory (libcruft/lapack, for
> example), the archive won't be updated unless you also go up one
> directory level and run make again.  Instead of worrying too about
> making that work correctly (I don't think it is possible without some
> changes to Make), I've just added a warning message that is printed if
> anything is done in a subdirectory.

O.K.   The recuse way was actually what I did at first.  I recognized
the problem and my solution was what you saw.  Both have there down
sides and it is really just a matter of preference.   
 
> One potential problem with these changes is the length of the command
> line that is generated for the ar command.  Some shells may choke on
> that.  But they would also have trouble with the command that builds
> the shared library version of libcruft, so maybe it won't cause any
> real trouble.
> 
> I think the patch below also prevents octave from being linked every
> time Make is run, even when it is not out of date (that's been bugging
> me for a long time, but I've not been motivated to fix it until now).

Great!   

So, I said in my previous email that I would make Octave be able to
build in parallel.  Well, I think I am going to back down from that
statement.  Here are the issues that would need to be resolved if some
one wanted to make it build in parellel.

1.  When building both static and shared libraries there seems to be
some race condition that can cause problems.   I did not track it down. 
I imagine it is probably not that difficult to solve.  

2.  In the event that liboctinterp finishes building before liboctave or
libcruft the linking of octave fails.  You could make liboctave and
libcruft dependencies of octave.  The problem with this is that you
would have two makes running in the same directory.  That is no
good.     What you really need is to make it say 'if liboctave and
libcruft are not built yet wait until they are'.  I do not see how to do
this with out completely restructuring the build process.    
Even if I could do it without a restructuring you still run into the
problem of what if libcruft or liboctave fail to build?  The the
algorithm I proposed would hang waiting indefinitely.   If a person
really want they can build in parellel like this:

gmake -j 4 -k MAKE='gmake -j 4 -k'  ; gmake 

I just thought you should no I changed my mind  now that I really
understand the scope of the problem.  The gains do not justify the
work.       

Thanks for listening.  

-- 
Ben Sapp                         Los Alamos National Laboratory
email: <mailto:address@hidden>   Phone: (505)667-3277
Fax:   (505)665-7920             URL:   http://www.neutrino.lanl.gov/
--