Re: What I learned today...

[Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de>]

On Thursday, February 28, 2013 11:22:06 Andrew Johnson wrote:
> On 2013-02-28 Michael Davidsaver wrote:
> > On 02/28/2013 09:57 AM, Benjamin Franksen wrote:
> > > (1) The script can be called more often than necessary:
> > I don't think this is the case as long as the command
> > './create_some_files.pl' creates all three files (which I assume it what
> > you intended).
> 
> If the target files can be created from more than one architecture and are
> generated in the O.Common directory or get installed into one of the common
> top-level directories (db, dbd, etc.) then you get this kind of problem, and
> it's actually very hard if not impossible to prevent a race between
> different target builds because they are not synchronized.
> 
> We get around that in Base now by always generating files into the O.<arch>
> directory and moving them into O.Common afterwards.  A move is an atomic
> operation in the file-system, so it doesn't matter if there is a race
> because the generated files *should* be identical.

But won't this mean that architecture independent targets (db files,dbd 
files,operator panels, etc.) will all be built several timesd (once for each 
target architecture)?

I may be missing something, but it seems to me that if 
CROSS_COMPILER_TARGET_ARCHS contains more entries than the machine has cores, 
make -j with rules that are as you describe above will be slower than serial 
make with the old make rules, at leats if the build time is dominated by such 
architecture independent targets. The latter is the case if e.g. device lists 
and configuration data are generated by scripts that query a SQL database 
server.

Cheers
-- 
Ben Franksen
()  ascii ribbon campaign - against html e-mail 
/\  www.asciiribbon.org   - against proprietary attachments

Attachment: signature.asc
Description: This is a digitally signed message part.