[Scons-users] Doing a build time Glob()

[Bill Deegan]

Marc,

In your example A install a bunch,etc.. make will not know about the
dependencies until you run make again.

If you know what files are output by a builder, you can have an emitter add
them to the dependency tree.
This is true of all build systems..(At least that I know of). Though I
don't know of many that you can do what a build emitter would do
(dynamically inserting dependencies during the build, though not after a
builder runs..).
If you're tool has a -n "as in don't do it, but just show me what you'd
do", then you could run that in your emitter and parse the output to figure
out the output files, it would be expensive (runtime wise) to do so, but
your build tree would be correct.

You can inform SCons of "token" dependencies that would force a build
order, but you're loosing correctness.

Correctness and repeatability are the main goal of SCons. (as well as a
certain amount of "batteries included" on understanding various build tools
and platforms, and also performance (which is still a work in progress))
It's very very unlikely you'll convince us to alter that.

-Bill



On Thu, Nov 28, 2013 at 2:23 PM, Marc Branchaud <marcnarc at xiplink.com>wrote:


> On 13-11-28 02:49 PM, Dirk Bächle wrote:

> > Hi,

> >

> > On 28.11.2013 17:05, Marc Branchaud wrote:

> >> On 13-11-28 04:04 AM, Pico Geyer wrote:

> >>> [...]

> >>> This is one of my top frustrations when using SCons to run external

> >>> (non-SCons) builds.  AFAIK there is no built-in way to do what you ask.

> >>>

> >>> SCons desperately needs to know about every file it deals with:

>  Either the

> >>> file is an original source (that exists in the "clean" project) or

> SCons

> >>> knows how to build the file.

> >

> > but isn't this true of every build system? If you tell "make" to install

> a

> > file, you either have to add a rule that tells it how to create the

> source,

> > or the file has to exist already. Otherwise you get a "don't know how to

> > create xyz" error, and this is what I'd expect from a decent build tool.

>

> SCons is more draconian about side-effects than other systems (like with

> the

> deleting of unrecognized files).

>

> Another aspect of this is that it's very difficult to work with SCons if

> your

> build tools don't create files with predictable names (e.g. Google Web

> Toolkit).

>

> There are clear benefits to having a static dependency tree, and to being

> strict about things that aren't in that tree.  But I feel that SCons is a

> little too militant, and it would be easier to use SCons to control

> non-SCons

> builds if there were some mechanism for updating the dependency tree after

> a

> Builder has run.

>

> I'd love to be able to say that a Builder's target is all the files that

> are

> in (& below) a directory after the Builder runs, even though I don't know

> what each of those files will be called.

>

> With make, I can have target A install a bunch of header files, then have

> target B compile something that uses those files, and B can depend on A,

> and

> I don't have tell make any of the names of the header files.  Sure this

> plays

> fast-n-loose with the dependencies, and sometimes this can trip make up,

> but

> sometimes fast-n-loose is exactly what you need.

>

>                 M.

>

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20131128/3f4311b5/attachment.htm