[Psi-Devel] make -j

[Davide Pesavento]

On Wed, Jul 15, 2009 at 20:01, Justin Karneges<justin-psi2 at affinix.com> wrote:
> On Wednesday 15 July 2009 03:32:47 Davide Pesavento wrote:
>> On Wed, Jul 15, 2009 at 09:27, Justin Karneges<justin-psi2 at affinix.com>
> wrote:
>> > On Tuesday 14 July 2009 23:53:40 Aleksey "AlekSi" Palazhchenko wrote:
>> >> aleksi at tower:~/Code/psi$ make -j3
>> >> cd third-party/qca/ && /usr/bin/qmake-qt4 qca.pro -unix -o Makefile
>> >> cd iris/ && /usr/bin/qmake-qt4 iris.pro -unix -o Makefile
>> >> cd src/ && /usr/bin/qmake-qt4 src.pro -unix -o Makefile
>> >
>> > Ah, it looks like the makefiles for subdirs all get made at the same
>> > time.  We need to fix this so src.pro doesn't get processed until later
>> > on (specifically, until some other iris .pro files are processed, but
>> > waiting until the iris dir is entirely built would work well enough too).
>>
>> Could you explain why you need these dependencies please?
>
> If you're asking, "why does src depend on iris at all?", that should be
> obvious.  If src finishes before iris, then you'll get a linking error
> because iris wouldn't exist yet to link against.

Yes, this is obvious, I was referring to the .pro processing :)

>
> If you're asking why the above .pro processing order is a problem, it's
> because we use qmake's prl feature for handling dependencies of static
> libraries.  qmake resolves dependencies by inspecting .prl files.  However,
> libiris.prl does not exist until iris/src/xmpp/xmpp.pro is processed.  This
> is a problem when qmake is processing src.pro too early, because the .prl
> files don't exist yet and won't be found.
>

I see, thanks for the explanation.

qmake's documentation for CONFIG=ordered is a bit vague [1]:
"When using the subdirs template, this option specifies that the
directories listed should be processed in the order in which they are
given."

This is clearly not happening if "directory processing" also involves
recursive qmake invocation inside those dirs. In this case, this
should be considered a qmake bug IMHO.

For a (non-hackish) workaround, what about running 'qmake -recursive'
at the end of configure?

Regards,
Davide

[1] http://doc.trolltech.com/4.5/qmake-variable-reference.html#config