Hi Ben,
On 2013-03-01 Benjamin Franksen wrote:
> On Thursday, February 28, 2013 11:22:06 Andrew Johnson wrote:
> > 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 times (once for
> each target architecture)?
In general no, although there can be times when they get built more than once
(hence the protection we had to add, see previous email). The main reason is
that we have a dependency in place so that no cross-builds can start until
after the host build has completed. Those files will usually be built and
installed as part of the host build, so make will see them as already up to
date when it later checks them for each of the cross-build targets.
> 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 least 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.
I don't claim to understand how make allocates build processes amongst sub-
makes when there is a limit given with the -j option, but I do know that it
doesn't end up allocating one process to each target architecture. If you set
up your rules so that the host build is the one that does the SQL queries and
installs a config file with the results then you can ensure that it will only
be run once. However if your SQL queries are architecture-specific they will
have to be done for each architecture anyway and the results should not get
installed into a common directory.
I have seen that builds on a single-core Windows system actually go faster if
you specify a small -j limit (maybe 2 or 3) than if you build serially.
- Andrew
--
There is no such thing as a free lunch. When invited for lunch,
it is best to check if you are there to eat, or to be eaten.
-- Clive Robinson
- Replies:
- Re: What I learned today... Benjamin Franksen
- References:
- What I learned today... Benjamin Franksen
- Re: What I learned today... Andrew Johnson
- Re: What I learned today... Benjamin Franksen
- Navigate by Date:
- Prev:
RE: areaDetector R1-9 released Mark Rivers
- Next:
Re: What I learned today... Benjamin Franksen
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: What I learned today... Benjamin Franksen
- Next:
Re: What I learned today... Benjamin Franksen
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|