[Scons-users] Dealing with headers appearing from Command builders

[mg at ncp-e.com]

Hi Dirk,

> You always have to provide this kind of information, if you want your
> dependencies being tracked correctly under all possible circumstances
> (parallel builds, variant dir builds, first build from scratch,...).

that's clear to me.

Maybe I didn't state my situation precisely enough. I don't even require
SCons to keep track of the files that result from third party software.
Third party libraries don't change frequently (and aren't modified by us
actively, apart from some applied patches maybe).

So what happens currently in our build system is that the package
manager, that is rather loosely coupled to SCons (thus the Command
builder), makes its own decisions what has to be done. It is always
called by SCons but only rebuilds third party packages if a
pre-configured version number changes or the package has not been built
yet.

The interface between the SCons world and the package manager world
mainly consists of the setup of include directories, libraries
directories and the library locations in the SCons environment.

I understand that this is somewhat of a mistreatment of the concepts of
SCons. It's a practical approach for our requirements of third party
software, however.

One could argue that it would be better to separate the two topics and
first build third party software, then after that run SCons on top of
the results. As we're building a variety of different software projects
out of the same SCons build system and require up to 60 different third
party packages its very nice that SCons knows just what third party
software is required for a specific target.

And it does really work nice the way it is already. It's just the glitch
that after the headers "appear" from third party packages SCons rebuilds
certain targets unnecessarily. Actually it would probably help me best
if I could achieve to tell SCons "just ignore the headers from that
directory".

> >     Knowing this only after the target is built doesn't really help
> >     me in the context of an Emitter or am I missing something?
> 
> Correct, that's why you'd have to parse the output of "tar tvf" or
> similar to get a list of filenames in advance.

Here lies the particular problem when trying to use an emitter for this
purpose. What is contained in the tarball is not necessarily what is
installed by the package's build system. Also among our third party
packages are more obscure build systems that do strange things at times.
So I can't really deduce from the files in the source archive what the
resulting, installed files will be.

I hope I was able to better explain the my situation this time.

Regards

Matthias

-- 
Matthias Gerstner, Dipl.-Wirtsch.-Inf. (FH)
Entwicklung
 
NCP engineering GmbH
Dombühler Straße 2, D-90449, Nürnberg
Geschäftsführer Peter Söll, HRB-Nr: 77 86 Nürnberg
 
Telefon: +49 911 9968-153, Fax: +49 911 9968-229
E-Mail: Matthias.Gerstner at ncp-e.com
Internet: http://www.ncp-e.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20150409/2c40c383/attachment.pgp>