[Scons-users] 回复： can I have a feature request: do a full buildprocess in the rule collect phase

[Viktor Dick]

On 11.09.2015 03:33, 查理王 wrote:
> It is absolutely the best idea to use Scanner when possible, but some
> tools do not have this feature and we can not modify it if it is a close
> source product. SIP is not the only example.
> 
> We use "scons in scons" when we do not any other way to finish it, or it
> is too trouble to write a scanner of it.

This topic was already discussed two or three times in the context of
finding the correct source files for an executable - not like here where
the source files first have to be created, but in a case where the
project tree has sources for multiple executables and it is not feasible
to include Glob('*.cpp') or some recursive variant thereof because not
all executables need all object files and this would induce unnecessary
rebuilds.

I guess the paradigm that the build and dependency tree can be
determined in one relatively short step might be the biggest weakness of
scons. In more complex builds, some information is only available once
part of the builds is finished. I guess it might be possible (although
it probably needs large changes in scons) to have a build system where
the initial script declares 'these are the possible final targets which
can be built. But in order to build this target, I do not know yet what
I will need. I will know it once this intermediate target is finished'.
Of course it is then not possible to print the complete dependency tree
without building anything, only a preliminary tree will be available.

My current solution (or rather workaround) is to build the complete tree
of "if this object file is included in some executable, these object
files also have to be included" during step 1, i.e. the SConstruct
script. This was first prohibitively slow, but it is OK if multiple
threads are used. So each file that contains a main routine (which is
called main_something.cpp) spawns a thread which calls 'g++ -MM' to get
the header files that are included, and, for each header that is not
already in the database and for which there is a source file, adds it to
the database and spawns a further thread for its dependencies. Once all
threads are joined, the targets are defined with the correct lists of
needed object files.

I do not know if in your problem there are many calls to SIP which each
take a small amount of time or if each call takes a long time. In the
first case, this workaround might also be applicable to you.

Regards,
Viktor

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150911/c3a2861b/attachment.pgp>