As a word of caution, we did something similar in the MongoDB tree for a
new kind of "library":
https://github.com/mongodb/mongo/blob/master/site_scons/site_tools/thin_archive.py#L53-L55
However, it doesn't fully work, because the SCons internals expect to be
able to transmogrify Nodes between
Hi scons-dev -
The following is a revised draft of an email that I had originally intended
to send as a follow up to
https://pairlist4.pair.net/pipermail/scons-users/2017-June/006018.html.
Instead, Bill Deegan and I took some time to expand on my first draft and
add some ideas about how to
Hi All -
With the SCons 3.0 release and GitHub migration completed (huge
congratulations to everyone involved), I'd like to revisit the discussion
from the summer about SCons performance.
This email is a follow up to
http://two.pairlist.net/pipermail/scons-dev/2017-July/004371.html
While there
I'm fairly clear on where SCons learns of the dependencies for source
files: that is in the CScanner attached to the SourceFileScanner in T
ool/__init__.py.
But where does SCons determine the dependencies of object files, such that
those dependencies are checked to see if the object file needs to
The simplest way to do what you want is to create a
> pseudo-builder that calls Object() and also calls Depends().
>
> -- Gary
>
> On Sun, Mar 25, 2018 at 1:07 PM, Andrew C. Morrow <
> andrew.c.mor...@gmail.com> wrote:
>
>>
>> I'm fairly clear on where S
I took a quick look through the MongoDB SCons setup, and I found once place
where we call get_ninfo. I agree that changing these to have clearer names
would be helpful, but it does feel like leaving in the old property names /
accessors would be useful for some period of transition.
On Wed, Mar
Hi Adam -
I'm working in this same area (caching and debug info handling) for the
SCons based MongoDB build system, right now.
Overall, I am trying to move to a model on Windows that is more like using
-gsplit-dwarf with the GNU tools, where every object file gets a
(cacheable) .pdb, and then we
