The dependencies for files are now global (see e.g.
trunk\main\solver\340\wntmsci12\workdir\Dep\CxxObject\svx\source\svdraw\svdobj.d
in a built win environment), it's not like in the old in-house build
system. This is because MKDEPENDSOLVER=TRUE is the default now (I ofteh
set that var since I needed glopal deps for incompatible builds from svx
which happened often to me).
Yes, the dependencies of the gbuild-ified modules such as svx are
handled automatically now, which is what I said. The build dependencies
from or to old-build modules are the problem.
Even the dependencies of the old modules are global (see e.g.
C:\aoo\trunk\main\sd\wntmsci12\misc\s_sdobjfac.dpcc), e.f. referring not
only to sd-internal files, but also to all delivered files in the solver.
Yes, these work IF the matching header files have already been copied to
the output trees.
As the build order and the build dependencies between the modules are
still managed by e.g. sd/prj/build.lst there is a race possibly
resulting in the header files not being "delivered" fast enough. Then
the local dependency magic sees the old unchanged files and does nothing
though it should if it had seen the updated files.
If the dependencies were not against the files in the output trees but
against the files in the modules themselves the mechanism could work
reliably. One would have to leave generated header files out of the
picture though.
Herbert
